こんにちは、プロダクト開発グループの増田です。普段は自社サービスの FANSHIP の開発・運用を行っています。
今回は、FANSHIP のとあるシステムを EC2 から ECS へ載せ替えたので、その時の振り返りを兼ねて書いてみたいと思います。過去に実施した同様の事例を踏襲しつつ、一部アップデートを加えているので、首記のようなタイトルにしてみました。
背景
FANSHIP システムは、アプリマーケティングツールとして、スマートフォンアプリと連動しながら様々な機能を提供しています。今回のシステムは以下の機能の一部を担っています。
- 通知の登録や、利用状況データの取得など（管理用 API）
- アプリ側からの通知取得など（エンドユーザー向け API）
- アプリ描画用の静的ファイルの提供
FANSHIP の中でも比較的長く使われてきていたシステムですが、インフラは手つかずな部分が多く、技術的負債が積み上がっていました。主に以下のような課題がありました。
- EC2 上に手動でサービスを立ち上げる構成で、アプリリリースのたびに煩雑な手順が走る
- リソースの切り分けがされておらず、効率が悪い
- 管理用・エンドユーザー用の API リクエストを同じインスタンスで受け付け
- 静的ファイルにも EC2 経由でアクセス
- 現在あまり使用していない AWS アカウントで管理されている
改修内容
ざっくり、以下のように構成を変更しました。
主な変更点は以下のとおりです。
ECS + CodePipeline でデプロイを簡略化
まず、アプリケーション基盤を EC2 から ECS に変更しています。同時に、CI/CD に CodePipeline を導入して、デプロイもパイプライン内で行えるようにしました。詳しい実装方法はこちらの公式チュートリアルがわかりやすいと思います。
これにより、これまでの
- EC2 インスタンス立ち上げ
→ Ansible によるサービス立ち上げ
→ テスト実施
→ ロードバランサーへの登録
→ 旧インスタンス削除
という手作業でのデプロイから解放されて、
- S3 にリソースをアップロード
→ 自動テストが通過した後に、リリース承認
だけでリリースできるようになりました。
CloudFront / ALB でリソースへのアクセスを切り分け
静的ファイルへのアクセスは、CloudFront + S3 が鉄板の構成だと思います。今回改修したシステムは、リクエストのおよそ 20 - 30 % ほどが静的ファイル（HTML + JS）だったので、まずそれらを CloudFront で振り分けるようにしました。これらはキャッシュが効くので、コスト削減効果も期待できます。
ついで、API アクセスについても、これまで全てごちゃ混ぜになっていたものを、ALB を使って管理用・エンドユーザー用とに振り分けています。これにより、個別に ECS のタスク量を調整したり、障害の影響範囲を限定させたりということが可能になりました。
アカウント移設
今回は移設しなければいけないリソースが少なかったのですが、やはり DB が厄介でした。夜間にもエンドユーザーから使用されるシステムだったため、できる限りダウンタイムを抑える必要がありました。そのため、以下の記事と同様の手法で DB のレプリケーションを作成し、Route 53 の向き先をバチッと切り替えるだけで入れ替えられるようにしました。なお、今回のシステムは Amazon RDS for MySQL を使用していましたが、作業自体はほぼ同内容だったため、過去の知見を活かすことができました。
もうひとつ言わせて: CloudFront のログは Datadog で監視しています
余談ですが、エンドポイント監視として CloudFront のログを使うために、Datadog も導入しています。CloudFront のログファイルをそのまま読むのはかなり辛いですが、Datadog は簡単な組み込みだけでパースしてくれるので気に入っています。
導入方法に関しては、こちらの記事が参考になるので興味のある方はぜひご覧ください。
ELB ログについて記載していますが、以下の設定をすれば問題なく転送してくれます。
- Datadog に CloudFront Log 用のパイプラインを追加
- Lambda のトリガーとなるバケットに CloudFront のログを連携
- 必要に応じて、フィルタリングの設定を調整（CloudFront のログはタブ区切り、かつ Datadog Forwarder 内で string 化されるので、区切り文字を
\\tにするのが味噌です。）
今後の展望
今回はスコープ外としましたが、さらなる改善として以下を検討しています。このシステムは今後、アクセス数の増加が見込まれているので、キャパシティ増強・スケーリング容易性の向上が喫緊の課題です。
- DB の Aurora 化（またはRead Replica の導入）
- ELB の AutoScaling 導入
最後に
弊社では、私達と一緒に自社サービス FANSHIP の開発を推進する仲間を募集しています。導入アプリ 300 件以上の大規模システムに関われるのは貴重な機会ではないでしょうか？今回紹介したような AWS をガッツリ使った基盤構築や、Python / Go を使ったアプリ開発に興味のある方は、ぜひご応募ください。
その他にも、オープンとなっている募集が多数あります。詳細は以下からご覧ください。
