エス・エム・エスで介護施設への入居マッチングサービス「安心介護紹介センター」の開発をしている中村と申します。「安心介護紹介センター」は2022年3月にローンチしたばかりの新規サービスで昨年から開発プロジェクトの担当をしています。

安心介護紹介センターはゼロからプロダクトを作るプロジェクトだったので、インフラの構成や監視など全てをゼロから考えて作る必要があったのですが、開発チームのメンバーでその経験が豊富な人はおらず、私にいたっては経験ゼロ。いつもインフラについては社内のインフラチームだったり他の誰かに設計・構築してもらい、自分はアプリケーションのコードを書くのみで、ALBもIAMもSecurity Groupも名前と役割は知っているけれど、自分でAWS環境で設定したことはありませんでした。またローカル環境構築のためにDockerを利用してはいましたが、コンテナでサービスを運用したこともありませんでした。

AWSよくわからん、コンテナよくわからん、という状態を脱したくて、自分で本を読んだりAWS Black Belt Online Seminarをみていたところ今回のプロジェクトにアサインされることになったので、これはスキルアップのチャンスになると思いすべて自分でやることにしました。

初めてのゼロからインフラ構築

こまったこと

今ならECSだよね...でも何から手をつけてよいのかわからんぞ...という状態でスタートしましたが、特に最初つまづいたのが以下の点です。

ECS運用のベストプラクティスは？
インフラの構成をコード管理するってどうやるんだろう？
コンテナのデプロイはどうやるの？
コンテナの定期バッチってどうやるんだろう？
Fargateのベストプラクティスは「sshを避けるというメンタルモデル」。sshできないって困らない？
ECSの監視って何でするの？

どう乗り越えたか

ECS運用のベストプラクティスは？

エス・エム・エス社内ではAmazon Web Services, Inc. のソリューションアーキテクトの方が定期的に勉強会を開いてくださっており、たまたま直前にDocker・コンテナ入門のハンズオンがあったので、それに参加しました。

ここでECSを使うメリットとECSでの開発・運用のベストプラクティスについて知ることができました。メリットデメリットと原理原則を正しく理解した上でサービスを使うことは大切なことなので、これを一番最初に、しかも専門家に教えて頂けたのはとても有益でした。

コンテナを使うメリットを生かすために、安心介護紹介センターではproductionとstaging環境は（マシンスペックという点は差分がありますが）、構成と使用しているDockerファイルは全く一緒にし、差分は環境変数(Parameter Store)で管理するようにしました。また、開発環境もなるべく本番と同様の構成になるようにしています。

この講習を受けてなかったらきっと環境によって差分をだしてしまって、コンテナ使ってる意味ないやん状態を作ってしまっていた可能性があったので、事前に原理原則とベストプラクティスを学べたのは良かったです。

インフラの構成をコード管理するってどうやるんだろう？

これはもう素直にインフラチームの方に相談して、今回はterraformを使うことにしました。(terraformを選んだ理由は社内でよく使われているから、程度の理由です。)ドキュメント調べまくりました。

コンテナのデプロイはどうやるの？コンテナの定期バッチってどうやるんだろう？

これは社内制度で購入した書籍を参考にして、デプロイはCodePipelineを中心にデプロイメントパイプラインを構築し、ECSへデプロイしています。

GitHubのmainブランチにマージ
GitHubからソースコードを取得
DockerイメージをビルドしてECRへプッシュ
ECRからイメージをプルしてECSへデプロイ

また定期バッチは、バッチの数が少ないのでECS Scheduled Tasksを使いECSのタスクを定期実行しています。（EventBridgeからタスクを起動する）

Fargateのベストプラクティスは「sshを避けるというメンタルモデル」。sshできないって困らない？

ECS運用のベストプラクティスに「SSHを避けるメンタルモデル」とあったので、SSHを想定した運用は絶対なしということを大前提にしました。そして運用時にサーバーへのsshするときってどんなときだろう...というのを洗い出して、それに対して別の解決方法を決めました。たとえば、

障害がおきたときに、原因を調査したい
- →デバッグに必要な情報は外部に送信するようにする。
  
  各種ログはALBなどS3にログを出力するものはS3に、ECSやRDSなどCloudWatch Logsに出力するのものは一定期間がたつとCloudWatch Logsから消えるようにしているので、監査上長期間保存が必要なログは、CloudWatch LogsからKinesis Data Firehoseを通してS3に保存しています。またアプリケーション側も調査に必要な情報をログに出力するように気をつけました。
DBのデータをみたい
- →AWS Elastic Beanstalkを使ってMetabaseを構築し、そこからDBのデータを参照できるようにした。
DBマイグレーションがしたい
- →なるべく作業は自動化したかったので、DBのマイグレーションはCodeBuild内で実行することにした。

ECSの監視って何でするの？

これはすでに社内で使用されていたMackerelを使用することにしました。調べてみるとタスク定義にmackerel-container-agentコンテナを追加するだけでOKでした。（もちろんMackrel側のモニターの設定などは別途必要です）

全体の構成をきめたら、そこで一旦社内のインフラチームの方にレビューして頂いて構成をここでFixさせました。

次にAWSのドキュメントとterraformのドキュメントを読み、環境構築をトライアンドエラーを繰り返して作っていきました。ここでもインフラエンジニアにレビューを必ずお願いするようにして、できあがったけどこれはあかんぞ、というようなことがないように間違えたらすぐ修正できるように進めました。

実際どうなったか

実際の構成はざっくりですが以下のようになっています。（ECSはオートスケーリング設定してあります）

まとめ

よかったこと

無事にリリースができたこと。そして今のところトラブルなし！

初めてのゼロからインフラ構築だったので「何もわからん」からのスタートで当初はかなりあたふたしましたが、新しいことは楽しいな！という気持ちで進められたのがよかったです。もう一回やりたいくらい楽しかったです。今回楽しいなと思えた理由は、以下の2つが大きかったです。

専門家が主催した勉強会で事前に正しい知識を学べたこと
チーム内外からのレビュー

エス・エム・エスでは誰でも参加できる社内勉強会があったりレビューの文化があるので、1人で悶々と悩んだり、間違えたまま突き進んでしまうようなことが起きにくいです。もちろん自分でドキュメントを読んだり勉強することは必要ですが、初めてやることは「これでいいのだろうか...」とやはり不安になるので、このような制度/文化があることは健やかな開発とスキルアップの助けになっています。

また技術選定は基本的に現場に任せられており、やったことないことでもどんどんやってみたまえ、という雰囲気なので、新しいことにチャレンジしやすい環境だったこともよかったです。