この記事は弥生 Advent Calendar 2022の16日目の記事です。
2022年5月、「証憑管理サービス（ベータ版）」*1の提供が開始となりました。
私はこのサービスの裏側で稼働するシステムの開発チームに所属しています。エンジニアのウエタケです。
このサービスの開発に携わる前、AWS経験はゼロ。
そんな私が新規サービスを構築するまでの道のりを、主にAWSサービスを使った観点から
モチベーショングラフ*2と共にふりかえってみたいと思います。
今考えるとこうすればよかった、これはやってよかった、というポイントをまとめていきますので、少しでも参考になればと思います。
モチベーショングラフ
まずは表題のモチベーショングラフから。
AWSを触り始める
出来事
- 新規サービスをAWSで構築することが決まる
- 自分のAWSアカウントを作ってAWSを触り始める
- とりあえずいろいろなサービスを触って楽しい時間を過ごす
- 何かができた気になる、今なら何でもやれそうな気がする
モチベーション
- AWSを触り始めたことが単純に楽しかったので、この時のモチベーションは高め
ふりかえり
まずは触って楽しむ
新しいことに取り組むときは、興味を持つことが学びの一番のモチベーションだと思っているので、まずは実際に動かして触り始めたのは良かったと思います。
AWSはアカウントを作成してから1年間、色々なサービスを無料で使える"無料枠"が用意されているので、この期間に色々と触ってみることをお勧めします。
余談ですが、現在弥生では社内で貸出用のAWSアカウントが用意されています。
なんとこれ、完全に個人の学習目的にも使うことができます。何ともありがたい仕組みですね～。
怖い記事を読んで震える
出来事
- AWSに触れ始める中で「アクセスキーが漏洩して外部から攻撃を受けた話」とか「設定を誤ってx万課金された話」とかいう記事を見かけ、恐怖感に苛まれる
- 記事を読んだ日は、自分のアカウントのリソースをすべて削除し布団を被って寝た
モチベーション
- 一旦手が止まったことで若干モチベーションは下降気味
ふりかえり
リスクの理解も大事
今考えるとポイントを押さえていればそこまで怯える必要はなかったのですが、記事のタイトルのインパクトにやられていました。笑
とは言え、何も考えずに使うとそのような事故が起こる可能性はもちろんあるので、リスクを認識し、理解して使うことが大事だと思います。
私は特に、以下の点に気を付けていました。
- セキュリティグループのインバウンドルールを最小限の公開範囲とし、不用意に外部からのアクセスを許可しない
- IAMのロールやポリシーを最小限の設定にする
- セキュアな情報（アクセスキーなど）をインターネット上に公開しない
予算アラートもオススメ
ちなみに、設定ミスによる課金に怯えた私はAWSの予算アラート*3を設定して心の安寧を保っていました。
外部からの攻撃で高額なインスタンスを立てられてしまった！というケースはアラートで気づいた時にはすでに遅いかもしれませんが、自身の設定ミスなどにより日々少しずつ課金されていた、というケースでは有効だと思います。
実際に私も、東京リージョン以外に作っていたリソースの削除漏れに気づかず、日々課金が積み重なっていたことがあります。
AWSのマネジメントコンソールから、どのサービスにいくら課金されているかを確認できるので、最初はそのあたりも見ながら慣れていくとよいと思います。
技術選定のため本格的に調査を始める
出来事
- 利用候補となるAWSのサービスについて本格的に調査を行う
- 公式ドキュメントの各サービスごとのページをベースに調査しようとして詰む。主な詰みポイントは以下
- サービスの概要や概念が理解できていないままドキュメントを読み、知らない単語や細かい設定に翻弄され時間を食う
- 類似機能のサービスを比較するために、それぞれのドキュメントを読んでいるうちに時間を食う
- 各サービス単体の機能や設定を逐一調べているうちに..以下略
モチベーション
- ドキュメントと格闘する日々。調査に苦戦しモチベーションはやや低め
- 進める中でAWSへの理解も深まり後半は徐々に回復
ふりかえり
まずは概要と概念を理解すべし
今考えると、ドキュメントの使いどころが分かっていなかったと思います。
まずはサービスの概要や概念を理解し、その後に各サービスごとのドキュメントを読んでいくのがお勧めです。 例えば、AWS サービス別資料のようなページは概要の理解に役立ちます。
サービスの特徴や類似サービスとの比較、使い分けなどについても触れていたりするため、理解しやすいです。私は後からこの存在を知り「最初にこれを知りたかった・・・」と思いました。笑
要件に立ち返る
また、そのサービスを「どう使いたいか」「システム（アーキテクチャ）として抑えたい要件はなにか」という観点を軸に調査を進めないと、ポイントを押さえた調査ができずに詰みます。 言葉にすると当たり前のことなのですが、使ったことのないサービスだったこともあり、ついサービスの機能面に寄った調査になってしまいがちでした。
サービスの機能や設定が多い（=柔軟な使い方ができる）というのはAWSのメリットでもある一方、
要件を押さえず網羅的に調査していくと、いくら時間があっても足りません。
私は調査とドキュメントに埋もれそうになるたびに、要件に立ち返るようにしていました。
ネットワーク周りの構築をはじめ絶望的な気持ちになる
出来事
- VPC含め全体のネットワーク構成の検討を始める
- VPC関連のどのドキュメントを読んでも頭に「？」が浮かぶ
- きっと今日は疲れているんだ、明日になれば理解できるはず..と1日塩漬けしたものの効果はなし
モチベーション
- いったい何からリソースを立てればいいのかもわからず、一気にモチベーションは下降
ふりかえり
力づくはやめよう
こちらの記事『そうだAWSで○○やってみよう、と思ったら』でも紹介されていますが、ネットワーク周りに関してはAWS公式のこちらのハンズオンが一番わかりやすかったです。
この辺りでVPC周りの概要を理解していれば、そこまで苦戦するポイントでもなかったと思います。
この時の私はハンズオンの存在を知らなかったので、VPCに詳しい人に聞きまわったり動画を見たり本を読んだりして、力づくで乗り越えました。
腕力とメンタルは鍛えられる（？）かもしれませんが、時間がかかるのでお勧めはしません。
検証環境を構築し始めAWSへの理解が進む
出来事
- 無事（？）ネットワーク周りを乗り越え、いよいよ検証環境に仮の構成を組み、動作を検証
- ここでの試行錯誤により、トラブルシュートの方法やはまりポイントも徐々に押さえられるようになる
- 検証環境で一通り各サービスが動いた日には、お疲れ様のラーメンを食べた
モチベーション
- 実際に手を動かしながら環境を構築し、徐々に全体の動きが見えてきたことでモチベーションが回復
ふりかえり
早めの検証環境構築が吉
今回の新規サービス構築では、以下の特徴がありました。
- 自身が運用経験のないAWSを使って環境を一から構築する必要があった
- 複数のAWSサービスを連携させるシステム構成だった
そのため、実際に環境を作って動かしてみると「サービス間の連携時の挙動や設定」、「インターフェースの細かい認識齟齬」など、いくつかの修正が発生しました。
今回は幸いシステム構成の見直しが必要なほどの問題は発生しませんでしたが、アプリケーションを作り込んだ後に基盤の構成変更が発生すると大幅な手戻りとなってしまいます。
そのため、ある程度利用するサービスと構成が決まった段階で早めに仮の環境を作って動かす、という工程が有効だと思います。
色々あったが運用開始
出来事
- なんだか色々あった、気がする
（雑） - 無事にサービス運用開始へ
モチベーション
- 無事運用開始にたどり着いた達成感で、モチベーションは上昇
ふりかえり
前半での地固めが功を奏す
なんだか色々あったと思うのですが、割と全力で駆け抜けていたのでこの辺の記憶があまりありません。笑
ただ、AWSに関してはこの段階ではあまり大きな問題は発生しませんでした。
これに関しては、開発の前半の工程で
- 事前にAWS側の技術調査をしっかりと行っていた
- 検証環境で動きを確認していた
ことが有効だったと思います。
さいごに
ふりかえると、AWSって何？という状態から、ある程度AWSの構成図も読めるようになり、自力でAWSの運用環境を構築できるようになりました。（ふりかえると感慨深い）
"自力で"とは書きましたが、ここに到達するまでにチームの人、チーム外の人にめちゃくちゃ助けてもらいました。
テクニカルな知識ももちろん大事ですが、こういった周囲の方の協力がなければここまで到達はできなかったと思います。
そういうチームで色々と学びながら新しいサービスを構築できたことは、私にとってとても学び深い、貴重な経験でした。
AWSは日々新しいサービスもアップデートされているので、そちらも追いかけつつ
今後もモチベーション高く、改善を続けていきたいと思います！
