こんにちは、インフラチームの橋爪です。
MOTEXテックブログの立ち上げに伴い、初投稿します。今回のテーマは、LANSCOPE クラウド版の開発環境についてです。地味なテーマですみません（笑
AWSマルチアカウントな開発環境とは
LANSCOPE クラウド版は、クラウド基盤としてAWSを使用しています。本番環境以外にも、開発環境３つとステージング環境１つ用意しています。
これらの開発環境/ステージング環境は、サーバースペックは本番より落としていますが、モジュール構成などは本番と同じ、ミラーリング環境です。
開発環境/ステージング環境は、それぞれ別AWSアカウントとして分けており（実際には AWS Organizations という概念でひとつのアカウントに紐付けられているのですが）、このように複数アカウントを管理することをマルチアカウントといいます。
以上が、AWSマルチアカウントな開発環境です。
なにが美味しいのか
開発環境が複数あると嬉しいのは、並列で開発や検証が行えるという点です。MOTEXでは、ロードマップ開発を複数ラインに分けて並列で行うことで、リリースサイクルの短縮を実現しています。
また、アカウントが分かれていることで美味しいのは、安全・安心な開発が行えるという点です。アカウントが分かれていれば、オペレーションミスで、本番のインスタンスを落としてしまった・・・、みたいな不幸な事故を防ぐことができます。
さらに、アカウント単位で分かれていると、コストを把握しやすいというのもメリットです。本番環境のコストと、開発環境で開発チームが性能試験を実施したことによるコストを見分けるのは一目瞭然です。
どのように実現しているか
同じ環境をレプリケーションするためには、インフラのコード管理が欠かせません。
LANSCOPE クラウド版では、アプリケーションはもちろん、インフラもコードから構築しています。主に CloudFormation と CodePipeline を利用しています。
こちら、CodePipeline でインフラをデプロイする時の様子です。
パイプラインの流れに沿って、リソースが作成されていきます。
同じ CodePipeline が各環境に用意されており、本番環境のインフラ構成に変更があった場合は、各開発環境のCodePipelineボタンを押して回ります。
環境停止の仕組み
とはいえ、本番環境と同じ環境が４つもあるとコストがかかります。API Gateway や Lambda のように、リクエスト毎に課金が発生するサービスは良いですが、Kinesis、EC2、ECS、OpenSearch Service、RDS、EMR といった時間課金のサービスは、立ち上がっているだけでお金がかかってしまいます。
MOTEXでは、コストを削減するために、チャットボットから環境の起動停止を行う仕組みを作っています。夜間や休日はインスタンスを消しておくことで、無駄なコストを抑えます。
起動する時はこんな感じ。
ここはイマイチと感じるポイント
チャットボットによる環境の起動停止は、環境単位でしか行うことができません。「一部の機能だけ検証したいのに」といった場合にも、全てのリソースを立ち上げる必要があるのは、コスト的に少し勿体無いと思うときがあります。
今後、機能単位で起動停止できるよう、ツールを改善できればと思っています。
まとめ
以上、MOTEXの開発環境事情でしたが、いかがでしたでしょうか？ 本番環境/開発環境で、AWSアカウントを分割するのは、AWSも推奨しており、セキュリティの観点からも分けたほうが良さそうです。 もし本番環境と開発環境が分離されていない場合、マルチアカウントな開発環境をご検討されてみてはいかがでしょうか？
