【TECH連載】社内の開発標準の取り組みについて #1 （AWSのインフラ環境整備の話）

【TECH連載】では当社エンジニアによるテック関連のニュースを中心に記事をお届けします！第二回は「社内の開発標準の取り組みについて #1 （AWSのインフラ環境整備の話）」について。

こんにちは、AICROSS開発チームの樋口です。

中途採用で入社して半年と少しですが、現在、社内エンジニアの開発標準の推進や技術レビューなど横断的に技術全般をみていく役割をやっています。

今回は前回のエンジニアからの社外発信ということで、これまでに実施してきた社内の開発標準化やインフラ整備などの活動についての事例を紹介していきたいと思っています。

AWSで稼働中のサービスのインフラ構成を整備した話

今回はAWSで稼働中のサービスのインフラ構成を整備した事例について紹介してきます。

本日紹介するインフラ環境の整備のポイント
・開発環境の分離
・構成管理対象の洗い出し
・設計ドキュメントの整備
・インフラ構成の整備
・デプロイ環境の準備

弊社では、提供するサービスは主にAWS上で構築しています。
入社して最初のミッションは、担当したサービスの運用設計でした。
ただ私が担当したサービスのインフラは当初以下のような状況でした。

・同一VPC内に複数のサービスが混在している箇所があった
・AWSの各リソースの命名規約が決まっておらず、どのリソースがサービスに紐づくのか見分けづらかった
・開発中のリソースが検証環境の中に混在していた
・本番、検証環境に不要と思われるリソースが多く存在していた
・本番、検証の各種AWSリソースの設定が不一致でどちらが正しいかわからなかった
・ドキュメントが古く仕様の多くは口伝となっていた

サービス１つ１つのインフラ構成で見ていったときにはAWSのベストプラクティスに近かったので、このまま大きな整備はせずに運用の中で手当てをしていく選択肢もありました。
ただ将来的にサービスが増えていったときにこの状態で構成管理をやっていくのは難しいと判断し、運用設計はいったん後回しで、まずこのインフラ環境を全体的に整備するところから手を付けています。

開発環境の分離

この状態でまず最優先で取り組むべきは開発環境を分けることです。
インフラ整備中もアプリ開発者の作業を止められないため、まずは開発環境を外出しして、東京リージョンにある本番、検証環境の整備に注力できる状況を作ります。
開発環境の外だしのための構成案は次の３案がありました。

案１．開発環境をVPCで分ける
メリット
・同じリージョン内のリソース移動のため開発環境の分離作業が楽にできる
デメリット
・VPCに紐づかないLambdaやDynamoDBなどのマネージドサービスは同じリージョンのコンソール上にフラットに並ぶため、開発リソースが分離したとは言いづらい
・同じリージョン内のため開発者のIAMの権限分離が難しく、開発者が本番、検証環境のリソースにアクセスできてしまう状況が解消できない

案２．開発環境をリージョンで分ける
メリット
・ほぼ完全に開発環境を分離できる(ただしCloudfrontなどグローバルなサービスは分離できない）
デメリット
・海外なので若干レイテンシーが遅い（今は大阪リージョンがあるためこのメリットは無くなりますが当時はシンガポールリージョンが選択肢でした）
・AWSサービスのBeta版やPreview版などの導入タイミングがリージョン事に違う場合がある

案３．開発環境をAWSアカウントで分ける
メリット
・完全に開発環境を分離できる
デメリット
・新たなAWSアカウントを作成した時の初期設定および運用でやるべきことがそれなりにある（パスワードポリシーやルートアカウントのMFAなどIAMの設定、CloudTrailのイベント監視設定等々）

結果的には案２の「リージョンで分ける」を採用しています。
案１は論外、理想は案３ですが、やはり全体として作業量が増えてしま事と、AWSアカウントが増えることにより今後の運用での管理対象が増えてしまうのを避けて不採用としています。
今回は
・グローバルサービスが少なかったこと
・アプリ開発対象は主にLambda/ECSでリージョン間の差分をそれほど気にしなくてよかった
を理由に案２の開発環境の分離でも十分と判断して案２を採用しています。

構成管理対象の洗い出し

開発リソースがシンガポールリージョンに引っ越した後に、東京リージョンに残った不要リソースをお掃除していきます。
お掃除は、リソース一覧を作って、１つ１つ各担当にこれは何？をヒアリングして消していきます、地味な作業になりますがこれが一番確実です。

誰の記憶にも残っていないけど存在しているリソース
　分かるまで調べる、分からなくてもバックアップして勇気をもって消す
・歴史的な経緯があって消してこなかったリソース
　同じくひも解いていき本来あるべき形にして消す
・集約可能なリソース（踏み台サーバなど）
　構成を整理して１つだけ残して消す
・将来的に使う可能性があって用意されているリソース
　今は使ってないのならバックアップをとって消す

ここで残ったものが全ての構成管理対象となっていきますので、不要なものは妥協なく１つ１つ蓋を開けて負債を全てつぶしていきます。
このタイミングで解消できない負債はもう一生返済できません。

設計ドキュメントの整備

次にサービスの整理を着手する前にまず設計ドキュメントを整備していきます。
設計ドキュメントはインフラ全体の共通設計と各サービスごとの設計に分けて整備していきます。
設計ドキュメントの整備の目的は次のとおりです。

・設計ポリシーのチーム内での共有
何かを変えていく時に、自分の考えを設計ポリシーという形でアウトプットにして、チームメンバーへの説明とフィードバックを地道に繰り返していく作業はとても大切な作業です。
また今後増えていくサービスも同じ設計ポリシーでインフラを構築していく必要があります。
そのためには設計ポリシーはチーム全体で共有できるようにドキュメントに残していきます。
決めるべきこと：VPC内の基本的な構成、各リソースの命名規約、共通的な設定値など

・チーム内の情報格差の抑制
リソースの１つ１つのこれは何？は人ではなくチーム（組織）で共有する知識です。チームで共有するべき知識はすべてドキュメントに残していかないとチームメンバーの入れ替え時のたびに情報格差が広がっていき、最終的に新規参加メンバーがストレスを抱える状態になっていきます。

・共有した情報の鮮度を維持するため
一度整備したドキュメントも運用保守の中で情報が古くなっていったら意味がありません。
構成変更などの仕様変更のタイミングで、体系的にドキュメントが整備されていなければ、その情報を残す場所がない開発者はチケットにしかその情報を残しません。
体系的に設計ドキュメントを整備していくことはドキュメントをメンテナンスする文化を組織に根付かせる第一歩です。

インフラ構成の整備

今回のサービスごとのインフラ整備はサービス単位でVPCを分けていく方針としています。
最終的な構成イメージは次のようになります。

VPCの分離は構成上プライベートサブネットのNAT Gatewayを分離することになるためAWSのコストは増加します。ただVPCを分けたほうがサービスの整理をしやすかった事と、前述の不要リソースの削除分でAWSのコストは相殺できると考えてこの方針としています。

リソースの命名規約は以下のように一目で本番なのか検証なのか、どのサービスなのかが一目でわかるように決めていきます。
（例）
本番 : prod-サービス名-機能名
検証 : stg-サービス名-機能名

インフラの整備作業は新しいVPCの作成から始まりますが、作業はすべてCloudFromationでおこないます。CloudFromationのテンプレートもgitで管理することにより今後のインフラの構成変更が履歴に残るようにしてきます。
またインフラの整備作業は以下もあわせて実施していきます。

設計ドキュメントと実リソースの整合性をとる
・命名規約等のルールの設計ポリシーをドキュメント化、命名規約に合わせてリソースの名称を統一
・各リソースの設定等を設計ドキュメントに反映
・アプリのgitリポジトリの整理、設計ドキュメントとgitリポジトリと実リソースの紐づけがわかるようにする

セキュリティ強化をする
・KMSの鍵を整理してS3,RDS,DynamoDB,EBS/EFS,SQSの全てにKMSの暗号化の設定をおこなう
・ALB/API Gateway/CloudfrontにWAFを設定
・セキュリティグループ／ロール／ポリシーの見直して各リソースへのアクセスは最低限のアクションとリソース範囲に限定
・ECS上のアプリが利用するアクセスキーなど秘匿性の高い情報はSystems Managerのパラメータストアに暗号化して保存
・アプリが利用するアクセスキーの権限見直して、最低限の権限のみ許可

AWSコスト管理の準備をする
・サービスごとのコスト管理のため、すべてのリソースに環境タグ(本番、検証）、プロジェクト（サービス）タグをつけていく

デプロイ環境の整備

インフラ整備後にアプリケーションのリリースに必要なデプロイ環境もあわせて整備していきます。

Lambdaデプロイの見直し
見直し前：各担当が開発環境でServerlessFrameworkを利用してデプロイ
見直し後：構成管理者が構成管理サーバでServerlessFrameworkを利用してデプロイ

ECSのデプロイの見直し
 見直し前: 各開発担当が各開発環境でDockerのイメージを作成後ECRにpush、その後AWSコンソール上でのECSタスク定義を更新
見直し後：構成管理者が構成管理サーバでDockerのイメージを作成後ECRにpush、その後CloudformationでECSタスク定義を更新

デプロイについては基本的に現行の仕組みをほぼそのまま踏襲しています。
将来的にはCodeBuild/CodeDeploy/CodePipeLineへの移行を想定していましたが、デプロイの仕組みは運用の中で見直しが可能なため、いったん運用に乗せる事を優先して大きく変更はしていません。

最後に

ここまでたどり着いたらあとはテストとデータ移行、最後にroute53でのDNSの設定でサービスの切り替えで完了となります。
大枠の概要となりますが、ここまでがAWSのインフラ環境の整備をしてきた話になります。

次回以降も開発標準化のためにやってきた取り組みについて紹介していきますのでよろしくお願いします。