こんにちは、開発エンジニアの熊田です。入社してから早くも2か月が経ちました。
今回は、AWSに触れる機会の少なかった私が、ある案件のアプリ基盤のリプレイス作業を担当した経験を振り返りながら、運用保守を外部委託するまでの話を書いていきます。
目次
AWSアカウントの分離
まず、リプレイス作業するにあたり、既存環境とは別に新環境用のAWSアカウントを用意しました。
AWS Organizationsを利用していましたので、アカウントは「組織の一部であるAWSアカウント」として作成しました。
背景 - これまで社内共通AWSアカウントで運用していた
AWSアカウントを分離する背景には、Insight Edge設立初期の案件という特有の事情がありました。
技術検証用AWSアカウントが用意されており、開発メンバは各々そこでAWSサービスを利用して開発作業を行ってきました。
いまでも技術検証目的で利用するアカウントですが、AWS Organizationsを導入する以前ですと、技術検証用AWSアカウントのまま本番利用するものがありました。
今回のリプレイス対象がまさに上記に該当します。これまでは社内メンバが管理していたので特に支障はありませんでしたが、社員の保守工数を下げる目的で外部委託することにしました。
共通アカウント上にあることで問題となるのは、委託先に開示してはいけないシステムとしたいシステムの区別ができないことです。
これに対処するには、別途AWSアカウントを作成する必要がありました。
新規AWSアカウントを作成
そもそもAWS Organizationsは、用途ごとにAWSアカウントを分けるマルチアカウント運用をする際には必須といえるサービスです。 公式サイトによると、AWSアカウントを一元管理するサービスで、1つの管理アカウントと複数のメンバーアカウントで構成されます。 アカウントを組織単位 (OU) にグループ化し、各OUに異なるアクセス ポリシーをアタッチできます。 さらに、メンバーアカウントの一括請求にも対応しています。
「組織の一部であるAWSアカウント」としてアカウント作成する手順は 公式サイト に載っており、簡単に実施できます。
アプリ基盤のリプレイス
さてさて、アカウントの準備ができました。
次に必要だったのは、旧環境の構成であるDocker on EC2から、Fargate&ECSへのリプレイスです。
EC2上でコンテナを動かす際に２つ課題が生じていましたので、それらに対応するためリプレイスを実施しました。
課題 - ストレージ不足とデプロイ作業の属人化
まずはストレージ不足による定期的なメンテナンス作業が必要であることがあげられます。サーバレスでない環境ではよく起こる問題です。
Linuxディストリビューションでのバックアップがストレージを逼迫させることがあり、サービスが停止することもありました。
もうひとつの課題は、デプロイ作業の属人化です。
最初にEC2上でコンテナを起動し、そのコンテナ上でソースファイルや学習モデルを更新していくため、初期のDockerイメージと乖離してしまっていました。
また、Dockerfileなども用意されていなかったため、現在使用しているDockerイメージが何をもとに作成されたのか、すぐには把握しきれなくなってしまいました。
最初に構築した人が作業する分にはこれまでの作業を把握しており大きな問題にはなりませんが、他の人が対応する場合はなかなか作業が進められない状況に陥っていました。
対応 - Fargateの導入とドキュメント整備
これら課題に対応するべく、Fargateを使うことにしました。
サーバレスであればストレージ不足に悩む必要もありませんし、諸々のメンテナンス作業からも解放されます。
また、もともとDockerコンテナを利用していたため、オーソドックスなFargate&ECS構成へリプレイスすることにしました。
構成図としては以下のような形になっています。
Application Load Balancer(ALB)の前にNetwork Load Balancer(NLB)を配置しています。 ALBのIPは動的に変わることを考慮して、この構成にしています。NLBにより静的IPを利用できるので、NLBのターゲットグループにALBを設定しています。 今回のアプリは、NLBのIPアドレスを利用してスプレッドシート（GAS）からAPIリクエストするため、上記のようにIPアドレスが変わらないよう対策しています。
構築する際は、こちらのブログを参考にさせていただきました。
Network Load BalancerのターゲットグループにApplication Load Balancerを設定する
もうひとつの課題であるデプロイ作業の属人化を解消するために、ドキュメント整備にも力を入れています。
外部委託先の方が困らないようにするためにも、初見の人でもデプロイできる手順書を作成しました。
具体的には、ローカル端末でのイメージ作成、ECRにPush、ECSサービスの更新を実施する手順です。
今回のアプリは本番運用開始から数年経っており、頻繁にデプロイされるアプリでもなかったので、今回はコスト的な観点から自動デプロイは用意しませんでした。
余談ではありますが、ECS Execを利用できるように設定しています。
これにより、ローカル端末からFargateのコンテナへ直接アクセスできるようになります。
SSH接続が不要であり、エラー発生時のトラブルシューティングにも活用できる利点がありますので用意しました。
運用保守の外部委託
新環境の構築が終わりましたので、ようやく運用保守を外部委託する話に移ります。
なお、外部委託するにあたって、NDA（秘密保持契約）は必須ですので、委託先への情報開示は締結後に行います。
マネージャに対応してもらっていましたので、詳細については触れませんが用語の説明を記載しておきます。
NDA（秘密保持契約）とは
相手方に開示する自社の秘密情報について、契約締結時に予定している用途以外で使うことや、他人に開示することを禁止したい場合に締結する契約
(引用元：https://keiyaku-watch.jp/media/keiyakuruikei/himitsuhojikeiyaku/nda/)
ユーザ管理と最小権限
システム面の話に戻ります。委託先のメンバが運用保守を行うためには、IAMユーザ、GitHubへのアクセス権限が必要になります。
IAMユーザについては、新しく作成したアカウントでIAMユーザを作成しました。
委託メンバは複数名いたので、グループを作成しポリシーをアタッチしました。
そして、グループにIAMユーザを追加します。
これにより、各メンバのアクセス権限をグループとして一括で管理できるようになります。
なお、グループにアタッチしたポリシーは最小権限に設定しています。
よく目にする用語だと思いますが、「最小特権の原則」に則っています。
セキュリティ強化を目的に推奨されてる原則で、障害や不正による被害を最小限に抑えられる効果があります。
GitHubについては、Organizationを利用しているので、outside collaboratorとして招待しました。 数あるリポジトリのうち一部しか参照してほしくないので、リポジトリごとに招待しています。 実際の作業は、GitHub管理者の方に実施いただきました。
役割の明確化
委託するにあたって、役割を明確にしました。当たり前な話ではありますが、仕事を進める上で役割・責任を明確にすることは重要です。
委託先には何を担っていただきたいか、一方、委託元であるInsight Edgeとしても何を担ったままなのか明確に定義しました。
そのうえで作業フローのイメージを共有することで、双方の仕事が進めやすくなるかと思います。
振り返り
今回の作業ではやらなかったことや、今後やってみたいことがありましたので、それらについてまとめていきます。
ECSではなくLambdaの方がベストだった？
コンテナを実行する構成としてオーソドックスなFargate&ECS構成を採用しましたが、リクエストの量、リクエストの時間帯が限定的なことから、Lambda実行にした方が、コストメリットがあったように思われます。
ただし、新環境自体は高スペックではないので、コストの差は微々たるものでした。
それよりもlambdaはコールドスタート問題があり、処理時間が想定より長くなる可能性があったため、今回はUXを優先してLambda利用を見送りました。
今回は検証できませんでしたが、SnapStart等でLambdaのコールドスタートを短縮出来る可能性があるので今後検証してみたいです。
IaCと自動デプロイ利用による改善余地あり
AWSサービスの構築はIaCを利用してコード化＆自動構築する方法もありましたが、今回はスピード優先としてコンソール画面から環境構築しています。
また、GitHubワークフローなどを用意して、自動デプロイする手もありましたが、今回の案件は開発及びデプロイ頻度が極まれでした。
そのため前述でも触れたとおり、手順書、DockerFileがあれば十分対応できることもあり、コスト観点からGitHubワークフローの用意は行っていません。
今後、追加開発などが始まり、環境構築、デプロイ頻度が増える場合には、それぞれの自動化を検討したいと思います。
終わりに
リプレイス作業と外部委託についての話は以上になります。読んでいただきありがとうございました。
Insight Edgeに入社して２か月経ちましたが、非常に充実した日々を過ごしています。弊社には、技術力の高い人たちが集まり、プロジェクトも挑戦的なものばかりです。
最初は私の慣れもかねてスタンダードな作業に取り組んでいました。そして、現在は新規サービスを開発する挑戦的なプロジェクトに関わっています。
前職では会計システム開発にずっと関わっており安定性重視の仕事をしてきましたが、いまは新しいことへ取り組む機会にあふれており非常にやりがいがあります。
いま参画しているプロジェクトでもたくさんの学びがありますので、次回はそのことについての記事を書いてみたいなと思います。
