はじめに
はじめまして！ プラットフォーム事業本部の桑名(@kuwana_kb_) です。 私はDMM.comのユーザーレビュー基盤を開発するチームでエンジニアをしています。
さて、ユーザーレビュー基盤では現在リプレイスを進めています。 今回はユーザーレビュー基盤の変革シリーズ 第4弾として「マイクロサービス化に向けたインフラ構成」と題し、ユーザーレビュー基盤のインフラをご紹介したいと思います。
なお、過去のユーザーレビュー基盤の変革シリーズは以下のリンクよりご覧いただけます！
旧システムで抱えていた問題
旧システムが抱えていた問題、それは「継続的なリリースが難しい」ということです。
前提として、旧ユーザーレビュー基盤は様々な機能が相乗りしたモノリシックなモジュール上に実装されていました。
一つのモジュールに複数の機能が存在すると、影響範囲を予測しづらくなります。
そのため、リリース時に意図しないエラーを引き起こすことがありました。
対策として入念にチェックを行わざるを得ないのですが、これがリリースまでのリードタイムに影響を及ぼします。
また、一つのモジュールを複数の部署が使用していたため、リリースにあたっては各部署との調整が必要でした。
これもリードタイムに影響を及ぼします。
つまり、リリースのたびに余分な時間とコストがかかるシステムだったと言えるでしょう。
この問題を解決するため、私たちはユーザーレビュー基盤を一つのプロダクトとして従来の基盤から切り出すことにしました。
いわゆるマイクロサービス化です。
次に、マイクロサービス化を進めていくうえでインフラに何を採用したのかをご説明します。
※ユーザーレビュー基盤以外のプロダクトも並行してマイクロサービス化を進めています。
新システムにはAWSを採用
新たなインフラ基盤にはAWSを採用しました。
AWSを採用するメリットは主に3つあると考えました。
まず、可用性、耐障害性において優れている点です。
オートスケーリングやマネージド・サービスの利用によって手軽に可用性・耐障害性を高めることができるのはクラウドならではのメリットだと思います。
次に挙げられるのは、インフラを自分たちのチームで運用できる点です。
チーム内で作業が完結することにメリットがあると考えました。
オンプレの場合、サーバーの構成変更などは別部署への依頼が必要になり、リリースへのリードタイムに響くからです。
最後は、 DMM社内でAWSチームやインフラのサポートを手厚く受けることができる点です。
DMMでは全社的にAWSの採用率が高く、社内ナレッジに知見が貯まっています。
また、DMM社内にAWSのソリューションアーキテクトの方が来てくださっていて、設計や運用で詰まった時に気軽に相談ができることもポイントです。
開発者としてとてもありがたい環境だと感じます。
新システムの構成
続いて具体的な構成をご紹介します。
まず、リクエストは CloudFront -> ALB -> ECS でさばく形にしており、負荷に応じてインスタンスがスケールします。
DBについては旧システムのオンプレDBからマイグレーションする要件があったためRDS(MySQL)を採用しました。
これらのリソースをマルチAZの構成にすることで、可用性を高めています。
また、ログ基盤には fluentd -> Kinesis Firehose -> ElasticSearch といった構成を採用しています。
運用を楽にするための工夫
ここまでご説明した設計は、AWSの運用において比較的オーソドックスな構成かと思います。
このなかでひと工夫している内容を2点ご紹介したいと思います。
1.Infrastructure as Code(IaC)化
「Infrastructure as Code」とは文字どおりインフラをコード化する、という意味の用語です。
私たちは新システムを構築するうえで、ほとんどのAWSリソースをソースコードで管理するようにしました。
具体的には、CloudFormationを用いてソースコード化し、GitHub Enterpriseのリポジトリで管理をしています。
イメージとしては、上記のディレクトリツリーのようにファイルごとに管理する形です。
IaCを実現することのメリットとしては、以下のようなものが挙げられます。
一点目は、リソースをソースコードとして可視化できるということです。
リソースをソースコードとして扱えると、リソースの変更履歴も追いやすくなります。
また、プロダクトを第三者に共有する時(ex.プロダクトの引き継ぎなど）もソースコードを読めば構成がわかるのでスムーズになります。
二点目は、リソースの構築にかかるスピードが劇的に早くなります。
テンプレートであるymlファイルをCloudFormationに適用すれば、一発で環境構築が可能です！
負荷試験や検証で本番と同様の環境を作りたい時にとても便利です。
ただ、IaC化にあたって注意すべき点もあります。
それは機微情報の扱いです。
具体的には、アクセスキー、シークレットキー、DBのパスワードといった外部に公開してはいけない情報の扱いに注意する必要があります。
こういった情報はCloudFormationのテンプレートに直書きせず、必要に応じてKMSを利用したり、SSMを通じてパラメータ化したりする必要があります。
2.エラーログのSlack通知
システムに問題が発生した際、重要な要素となるのがログです。
問題のあるログを即座に検知するためにAWSとSlackの連携を強めています。
まず、インスタンスに異常が発生した場合に関して。
こちらについては、 CloudWatchMetricsでECS, RDSのCPU使用率などをメトリクス化し、CloudWatchAlarmでメトリクスの数値を監視しています。
もし異常を検知した場合は、CloudWatchAlarmがLambdaをキックし、Slackに通知が来るようにしています。
次にアプリケーションレイヤーに異常が発生した場合に関して。
こちらはECS+fluentdで各種アプリケーションログを出力できるようにし、Kinesis経由でS3にログを保存しています。
緊急の対応が必要となるerror.logは、S3への保存をトリガーとしてSlackに通知が来るようにしています。
このようにレイヤー別にエラーを検知する仕組みを作っておくことで、問題への対応速度を向上させると同時に解決への手がかりを増やすことができるというメリットがあります。
まとめ
今回はユーザーレビュー基盤のマイクロサービス化におけるインフラ構成と、運用を楽にするための工夫をご紹介させていただきました。
IaC化、Slack通知どちらも便利なのでぜひ試してみてください。
また、今後もユーザーレビュー基盤での取り組みをご紹介予定ですので、引き続きそちらもお楽しみに！
最後に
私の所属するプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。
それぞれの得意分野を活かしながら、みんなでフロントエンドからインフラまでフルスタックを目指しているチームです。
少しでもご興味のある方はぜひご応募ください！