YOUTRUSTのインフラの全体像

こんにちは。CTOのzoo（YOUTRUST/Twitter）です。

今回は、YOUTRUSTのインフラの全体像を紹介したいと思います。

AWSとGCPの使い分け

YOUTRUSTでは、AWSとGCPの2つのクラウドサービスを利用しています。

メインとなるサービスのインフラはAWSを用いて構築しています。 YOUTRUSTのサービスのほぼ全てをAWS上で動作させています。 AWSはサービスを開始した5年ほど前から利用しています。

GCPは1年半ほど前から利用しています。 利用のきっかけはデータ基盤をBigQueryに移管することでした。 また、1年ほど前から機械学習を用いたレコメンド機能を提供しているのですが、モデルの学習はGCP上で行っています。 つまり、データ基盤およびそれに付随するような機能（要素）はGCP上に乗っています。

YOUTRUSTのインフラに用いられている主要なリソースと構成の雰囲気
主要なリソースと構成の雰囲気

主要なリソースと構成の雰囲気は上図のようになります。ネットワーク関連は完全に省略しております。

AWSとGCPの間には次のようなゆるいつながりがあるだけです。

  • AWSからGCPへのStorageTransferを用いた分析用データの転送
  • AWS上のアプリケーションからGCP上のレコメンド用APIへのリクエスト

AWSの環境とTerraformでの構築

AWS上にProduction環境、Sandbox環境、Development環境を構築しています。 構成管理にはTerraformを用いています。 Terraformのカバー範囲はほぼ全てで、体感では98%以上の範囲をカバーできています。

AWSアカウント

各環境用のAWSアカウントを AWS Organizationsを用いて作成し、それぞれの環境が完全に独立するようにしています。 なお、実際にはControl Towerを用いてセットアップしています。 また、IAM Identity Centerを用いることで、各環境へのログインやユーザーの管理を最小の手間でできるようにしています。

下図は、各アカウントにログインするためのポータル画面のスクリーンショットです。 実際の環境のセットアップにはControl Towerを用いているため、Production、Sandbox、Developmentのアカウントの他に、Log Archive（ログアーカイブアカウント）とAudit（監査アカウント）が存在します。

そして、当然ながら、各環境、メンバー毎に適切なパーミッションを設定しています。 また、見ていただいて分かる通り、複数のパーミッションを付与することで、作業内容によってパーミッションを使い分けられるようにしています。

AWSの各アカウントにログインするためのポータル画面
各アカウントにログインするためのポータル画面

各環境の用途

Production環境

サービス提供に利用している環境です。 本番環境と呼んでもいます。

Sandbox環境

本番と同じインフラ構成の環境です。 ただし、コスト観点でスペックは抑えています。

  • インフラ構成を変更する場合の挙動の確認
  • 脆弱性診断の実施
  • 後述するDevelopment環境で動作確認ができないアプリケーションの動作確認

などが主な利用用途です。

Development環境

Production環境やSandbox環境とは全く違うインフラ構成です。

などが主な利用用途です。

Development環境では、数台のEC2インスタンスを立てて、それぞれのインスタンス上でDockerを用いてアプリケーションを動作させています。 複数のメンバーがそれぞれ異なる機能の動作確認を行ったり、iOS/Androidの開発のバックエンドとして利用したりしています。

また、これまでに利用経験がないAWSのリソースを試してみる、という時にもDevelopment環境を気軽に利用しています。

Terraformの利用方法

AWSの環境構築のためのTerraformのGitHubレポジトリは全部で4つあります。

  1. Production環境とSandbox環境（Route53を除く）用レポジトリ
  2. Production環境のRoute53用レポジトリ
  3. Sandbox環境のRoute53用レポジトリ
  4. Development環境用レポジトリ

まず、Route53に関してはレポジトリは分けています。 これは、システム開発以外の文脈でのサブドメインの追加等が発生することがあり、クイックに対応できた方が良いことがあるためです。 本体と同じレポジトリにすると、作業が重なった場合などに面倒なことが発生することがあるため、それを避けたいという意図になります。

そして、Production環境とSandbox環境に関しては、基本的に同じ構成としたいため、同じレポジトリを用いています。 ディレクトリ構成は下記のようになっています。 コンポーネントを作成し、それを各環境構築に利用する、という形をとっています。

.
├── README.md
├── components
│   ├── backend
│   ├── bastion
│   ├── chatbot_alarm
│   ├── data_platform
│   ├── deployment
│   ├── health_dashboard_notification
│   ├── iam
│   ├── network
│   ├── opensearch
│   ├── security
│   ├── tfstate_backend
│   └── webapp
└── environments
    ├── prod
    └── sandbox

Development環境に関しては、Production環境とSandbox環境とは構成が全く異なるため、別レポジトリにしています。

GCPの環境とTerraformでの構築

基本的な思想はAWSと同じです。 ただし、GCPではアカウントで環境を切り分けるのではなく、プロジェクトで環境を切り分けています。 また、データ基盤用のプロジェクトとアプリケーション用のプロジェクトも別にしています。 これは、それぞれを扱うチームが異なるためです。

まとめると、次の4つのプロジェクトを利用しています。

  • データ基盤用
    • Production環境用プロジェクト
    • Sandbox環境用プロジェクト
  • 機械学習用
    • Production環境用プロジェクト
    • Sandbox環境用プロジェクト

GCPの環境構築のためのTerraformレポジトリは、データ基盤用と機械学習用で2つあります。

AWSとGCPの連携

AWSのProduction環境とGCPのProduction環境、AWSのSandbox環境とGCPのSandbox環境が連携しています。 そのため、AWSとGCPを跨いだ動作確認も、Sandbox環境で行うことができるようになっています。

終わりに

今回はインフラの全体像を紹介しました。 「整っている！」と思っていただいた方はぜひ"はてなスター"をつけていただければと思います！ そして、今後はより詳細にフォーカスした内容をお伝えしていければと思いますので、ご期待ください。

唐突ですが、7/12（水）にイベントを行います。 インフラの詳細について、AWSのコンソール画面を映しながら話す予定でいます。 ぜひご参加ください！

youtrust.connpass.com