AWS ECS、Fargateを使ったGtax for Enterpriseのインフラ構築
こんにちは。仮想通貨の損益計算ツール「Gtax」、仮想通貨の確定申告サポート「Guaridan」を提供するAerial Partnersのエンジニアインターンの伊藤です。
今回はGtax for Enterpriseのインフラをコンテナオーケストレーションサービス Amazon ECSおよびAWS Fargateで構築した際の話をします。
Gtax for Enterprise
Gtax for Enterpriseは、ブロックチェーン企業の経営管理体制・経理財務フローの効率化を支援するサービスで、Dappsゲームの運営会社や、仮想通貨取引所などに提供しています。
近年、金融庁の規制、監督の強化もあって、事業者がブロックチェーン上のアセットの取引を管理する基盤を整える必要性が増しています。日本の制度に対応した会計管理システムの開発には、ブロックチェーン領域に精通した会計のスペシャリストとIT技術者の双方が必要です。
Aerial Partnersは、仮想通貨投資家向けの確定申告をサポートするサービスとしてGtaxを開発していた経験を生かして、業界横断的な管理会計の標準を提供するために、事業者向けの高度な機能を備えたGtax for Enterpriseの提供を始めました。
そして、Gtax for Enterpriseの開発で取り組んだことの一つが、Amazon ECSとFargateによるインフラ構築です。
Amazon ECS
Amazon ECSとは、AWS独自のコンテナ技術を使ったコンテナオーケストレーションサービスです。
コンテナオーケストレーションサービスとは、dockerなどのコンテナのオートスケーリング、ホストマシンにまたがるコンテナの配置などを行うツールです。ECSの他に有名なサービスだとKubernetesがあります。
要するに、「どのホストマシン」で「どのコンテナ」を「いくつ起動する」かなどのハンドリングをするサービスです。
ECSはAWS独自のコンテナ技術を使ったコンテナオーケストレーションサービスで、Amazonのサービス内でも広く使用されており、高いセキュリティ、信頼性、可用性の実績を持っています。また、その他のAWSサービスとスムーズに連携できる特徴を持っています。特に、後述するFargateというサービスを利用できるというのが、今回ECSを採用した理由の一つです。
AWS Fargate
AWS Fargateとは、ECSで利用できる、サーバーレスコンピューティングエンジンです。ECSでは、自前で用意するEC2でのホスティングを選択することもできます。しかし、EC2でのホスティングでは、 OS バージョンアップなどのセキュリティ対策を自前でやらなければなりません。また、可用性を高く保つためにはMulti AZでの構成や緊急時に復旧するための体制作りが必要となります。
Fargateは、それらのホストマシンの管理運用を全てAWSにやってもらうサービスです。Fargateを利用することで、高い可用性とセキュリティを保ちながらホストマシンの管理運用コストを下げることができます。利用も簡単で、MultiAZもすぐ構成できます。
昨年のAWS東京リージョンの大規模障害の際には、FargateでMulti-AZ構築を行っていたサービスは、Fargateによってホストマシンが障害のないAZに切り替えられ、ECSによってコンテナがデプロイされることで自動で素早い復旧を実現したと言われています。
Gtax for EnterpriseにECS、Fargateを採用
Gtaxはフロントエンド、バックエンド、ジョブワーカーなどで構成されていますが、従来はそれらをEC2インスタンスでホスティングしていました。
これまではGtaxはコンシューマー向けのみの展開だったので、監視体制を構築したり、コストをかけてセキュリティ対策ソフトを導入したりする環境も1つですんでいました。
しかし、Gtax for Enterpriseとして、仮想通貨取引所などのエンタープライズ向けにもサービスを卸していくことになりました。
事業者ごとにDBや接続先の外部サービスを分けて提供するため、複数の環境を管理していく必要があります。必要なマシンのスペックやピーク時間も異なります。また、仮想通貨取引所などに対してはセキュリティ、可用性ともに非常に高いレベルのシステムを提供することが要求されます。
そのような状況でEC2インスタンスでのホスティングを続けていくのは難しく、コンテナ技術やFargateを活用できるECSでのホスティングに移すことにしました。
コンテナ化することで確実に動作する状態でアプリケーションをバージョン管理できたり、マイクロサービス化した各サービスのスケーリングが容易になりました。
Fargateを利用することで、ホストマシンの管理をAWSに任せることができ、管理コストやセキュリティソフトの運用コストを抑えながら高いセキュリティと可用性の要件に応えることができるようになりました。
ECS運用のアーキテクチャ
ECSにてサービス環境を1つ作成したときのアーキテクチャを示します。サービスのホスティングの構成の他に、サービスを継続的に運用する際に必要なデプロイフローを構成するコンポーネントも含んでいます。
GitHubにコードベースがpushされると、AWS CodeBuildによってビルドプロジェクトが始まります。CodeBuildはコードベースに含まれるソースコード、Dockerfile、ビルド仕様を定義するファイルを使用してdocker imageを作成します。
docker imageはAWS製のContainer RepositoryであるAmazon ECRにpushされます。また、ビルドプロジェクトの経過などはAmazon SNSとAWS Lambdaを通じてSlackに通知されます。
Developerはdeploy serverにログインし、新しく作成されたdocker imageをECSにデプロイすることでリリースします。
ECSはECRからdocker imageをpullし、Fargateによって確保されたリソースにコンテナをデプロイしていきます。必要なコンテナが正常に動作を始めたことを確認すると、ECSによってロードバランサーからのルーティングが新しいリリースに切り替えられます。切り替えが完了すると、それまでの古いリリースのコンテナは停止され、利用されていたリソースがFargateによって開放されます。
アプリケーションのコンテナ化
今回はGtaxを構成するサービスのうち、以下をコンテナ化しました。
- バックエンドサーバ（Laravel）
- ジョブワーカ（Laravel）
- マイグレーション（Laravel）
- DBシーダ（Laravel）
- フロントエンドサーバ（Nuxt）
- HTTPサーバ（Nginx）
当初はマイグレーションとDBシーダのコンテナがなく、バックエンドサーバのコンテナが立ち上がる際にそれらを実行するようにしたり、ジョブワーカコンテナでsupervisorを利用してワーカーを複数プロセス立ち上げるようにしたりしていました。しかし、スケーリングの自由度や監視のしやすさ等を考えていった結果、それらも分離しました。
最初は、管理や把握が複雑になる予感がしたりしてなんとなくコンテナを増やすことに抵抗がありましたが、次第に「1コンテナ1プロセス」の原則に従うことがコンテナの利点を活かす前提だということに気づきました。Laravelの各コンテナはコードベースが共通しているので、コンテナを分けてもimageは1つで済みますし、心配していたような管理の複雑化も起こっていません。
ECSとAWSの他サービスとの連携
前述したように、ECSにはAWSの他のサービスとの連携がスムーズに行える特徴があります。
例えば、機密情報の取り扱いもKMS、SSM、IAMなどのサービスを利用してAWSマネージドで完結した方法でシンプルに行うことができます。
コンテナには実行時に環境変数を与えることができますが、ECSでもデプロイ時に環境変数をコンテナに与えることができます。
今回のアーキテクチャでは、環境ごとに異なるパラメータはdeploy serverからECSにデプロイを行う際に環境変数で設定するようになっています。
しかし、deploy serverに保存しておきたくない機密情報もあります。そのようなときは、SSMのSecret Parameterを起動時に展開するECSの機能を利用します。deploy serverに保存するのはKMSによって暗号化した機密情報のみにすれば、deploy serverからは機密情報を排除することができます。また、タスク実行ロールにSSMとKMSの利用権限を与える際にはIAMが利用できるので、AWS上でセキュリティ管理を行うことができます。
余談ですが、コンテナオーケストレーションをAWSマネージドで行うサービスとしては、ECSの他にKubernetesベースの「EKS」があります。2019年12月には、EKSでもFargateを利用できるようになりました。EKSと他のAWSのサービスとの連携も強化されてきていて、Kubernetesがコンテナオーケストレーションのスタンダードになる流れは続いているようです。
終わりに
Aerialのメンバーと一緒に話してみたい、ブロックチェーン技術の社会実装に興味がある、という方はぜひ一度私たちとお話しにオフィスまで遊びに来てください！
エンジニア募集
