こんにちは。DIGGLE エンジニアの miyakawa です。
普段はバックエンドとインフラを中心に開発しています。
今回は、前回の記事で触れたレポート機能の数値検証の「実行環境」についてお話したいと思います。
レポート機能の数値検証の内容については前回の記事をご覧ください。 diggle.engineer
数値検証の実行環境
まず結論として、現在は数値検証の実行環境として AWS の Cloud9 というサービスを利用しています。
Cloud9 はクラウドベースの統合開発環境（IDE）を提供してくれるサービスです。
IDE なので開発環境としての用途が一般的かと思いますが、弊チームでは検証用スクリプトの共有実行環境として活用しています。
次に Cloud9 を採用した経緯についてお話しします。
実行環境選定の経緯
ローカル環境での課題
当初、数値検証の実行は開発メンバーのローカル環境 （PC）上で行っていました。
数値検証には本番環境のデータベースのデータを複製したデータベース（以降、数値検証用 DB）を用いますが、セキュリティ上ネットワーク外部からの直接アクセスはできないようになっています。
そこで、ローカル環境から数値検証用 DB へアクセスするために、EC2 インスタンスによる踏み台サーバを用意し AWS Systems Manager の Session Manager を使ってセキュアにログイン、数値検証用DBまでポートフォワード接続できる環境を構築していました。
しかしながら、このローカル環境で数値検証を行う方法では以下の問題がありました。
- 数値検証の実行完了まで数時間かかり、その間ローカル環境のリポジトリのブランチは固定かつ PC リソースも消費されるため開発作業に支障が発生する
- 40〜60分ほどで Session Manager の接続が切れて数値検証の実行が途中で止まってしまう*1
二つ目の問題については、数値検証スクリプトに途中の段階からリトライするオプションがあるため、実行が止まるたび都度リトライすることで対処していましたがかなりの手間となっていました。
ローカル環境以外の方法の模索
ローカル環境を使う運用は難しいと判断し、それ以外の方法を検討し始めました。
ここで一度数値検証の実行環境の要件をまとめます。
- Rake タスクを実行できる or Docker コンテナを実行できる
- リポジトリの任意のブランチで実行することができる
- AWS のプライベートネットワークにある数値検証用 DB にアクセスできる
これを踏まえて検討した結果、以下のような案が出ました。
- EC2 インスタンスにローカル環境と同様の環境（git + Docker）を用意して数値検証を実行する
- 上記に加えてジョブ管理ツール（Rundeck など）を導入して Web ベースで作業できるようにする
- Github Actions のワークフローとして実行する*2
- 数値検証用 DB アクセスのために EC2 インスタンスで self-hosted runners を構築する
いずれも AWS 上に EC2 インスタンスを作成するという点は同じで費用面でのコストに差はありませんでした。
後は工数との兼ね合いかと考えていたところで、AWS のソリューションアーキテクトの方と相談の機会があり本件についても相談してみました。
すると
「Cloud9 が適しているのはないか」
とのご助言が...！
それまで Cloud9 は使ったことがあってもあくまで開発環境用というイメージしかなかったため目から鱗でした。
早速 Cloud9 による環境を検証したところ、次に述べる Cloud9 の利点から、先に検討していた各案よりも優れていると判断し最終的に採用へ至りました。
Cloud9 の利点
環境作成が容易
Cloud9 の EC2 環境では EC2インスタンスをベースにクラウド IDE 環境を構築できます。
AWS コンソールからネットワーク（VPC）や接続方法等の最低限の情報を設定するだけで、すぐに開発を始められる EC2 インスタンスが作成されます。
（Cloud9 の環境作成方法の詳細については こちら を参照ください）
IDE の機能を除いたとしても、一から EC2 インスタンスをセットアップする場合と比べて多くの利点があり、セットアップの工数を減らすことができます。
例えばですが、
- （接続方法として選択した場合）Session Manager の設定が自動で行われる
- git、docker といった開発に必要なツール群がプレインストールされている
などが挙げられます。
IAM ユーザによる共有
Cloud9 の環境は作成時点では作成者のみが利用できる状態です。 そこに IAM ユーザを招待する形で他の開発者に環境を共有することができます。
仮に素の EC2 インスタンスへの Session Manager によるアクセスを IAM ユーザごとに可否設定する場合は各 IAM ポリシーを設定する必要が出てきますが、Cloud9 であればクラウド IDE 上で操作するだけなので非常に管理が楽になります。
また CloudTrail から証跡（いつ、どの IAM ユーザが Cloud9 を利用したか）も確認できるため、万が一の時のためにも安心です。
費用削減の機能がある
開発・検証用の環境は常に利用するわけではないため、夜間停止などの仕組みを入れたくなると思います。
EC2 インスタンスであれば AWS Systems Manager Automation を利用するなど一工夫が必要になります。
一方で Cloud9 にはセッションがなくなった後に一定時間が経過後 EC2 インスタンスを自動で停止する機能があります（停止するまでの時間は選択可能です）。
これにより、Cloud9 を使用する時のみ EC2 インスタンスが起動している状態となるので、費用の無駄を防ぐことができます。
Cloud9 環境セットアップ時の注意点
Docker Compose はインストールされていない
前節で docker がプリインストールされていると言いましたが Docker Compose はインストールされていません。
Docker Compose が必要な場合は、Docker の公式ドキュメント を参考にインストールしましょう。
ディスクサイズの拡張
Cloud9 のデフォルトのディスクサイズ*3は 10GB でその内大半はシステムで利用されており、環境作成時点でユーザが利用可能な領域は 2GB 程度です。
これでは多少大きめの Docker イメージをいくつかプルするだけであっという間にストレージが枯渇してしまいます。
そのため、環境を作成した時点でディスクサイズを拡張しておくことをおすすめします。
まとめ
今回は数値検証の実行環境として Cloud9 を採用するまでの経緯について紹介しました。
Cloud9 は他にもいろいろと活用できそうに思っているので、今後も新しいユースケースが出てきたら紹介していければと思います。
We're hiring!
DIGGLEでは最高のプロダクトを一緒に作ってくれるエンジニアを募集しています！少しでも興味があれば、ぜひ下記採用サイトからエントリーください。
Meetyによるカジュアル面談も行っていますので、この記事の話をもっと聞きたい！という方がいらっしゃいましたら、お気軽にお声がけください。
*1:主にポートフォワードの接続が切れるという状況。調査したところ Session Manager のセッションタイムアウト（https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-preferences-timeout.html）が原因ではないことは分かりましたが、根本の原因は分かっていません
*2:弊チームでは CI として Github Actions を利用しています
*3:Cloud9 の環境は EC2 インスタンスで構築されているので、ディスクサイズ = EBSのボリュームサイズを示します
