2025年版にアーキテクチャ図を書き直してみた

インフラ AWS

こんにちは！SRE2年生に突入した墨(YOUTRUST/X)です！
今年もあと1ヶ月となりましたね！
私事ですが、YOUTRUSTに入社して9月で1年が経ちました。
YOUTRUSTのインフラ構成についてもだいぶ理解が深まってきましたので、この機会に2025年最新Verとしてインフラアーキテクチャ図を書き起こしました。 また、前回のインフラのブログはこちらです！

tech.youtrust.co.jp

🌍 アーキテクチャ図全体像

※ マルチAZ、DBのサブネットなども分割されていますが、NW的な分離は見やすさ重視で省略しております。

それでは個別に構成を見ていきましょう！👀

📱 メインアプリについて

YOUTRUSTのアプリケーションはざっくり分割すると、以下の3つの機能群で構成されています。

  • toC向け: SNS機能
  • toB向け: 採用・営業担当者向けダッシュボード
  • 社内向け: Admin管理画面

アプリケーション層

通信の入り口としてはWAFがアタッチされたALBが受け、ECS on Fargateでホストされたサーバーへ振り分けを行います。
現状、Rails アプリ（Web）と非同期ジョブ（Sidekiq）はそれぞれ独立した ECS サービスとして稼働しています。
また、社内Admin 向けとユーザー向け（toC / toB）のアプリケーションもサービス単位で分かれており、合計 4 つの ECS サービス構成になっています。

上に載せた以前のブログで分かる通り以前は2つのECSサービスだけでしたが、アプリケーションコードの肥大化や責任と障害点の明確化などを理由に社内用のAdminアプリケーションをコード、ECSサービス単位で分割しました。 具体的な施策は下記ブログをお読みください！

tech.youtrust.co.jp

データベース層

DBは Amazon RDS for MySQL を採用しており、リードレプリカを2台稼働させています。
DB管理者は、EC2踏み台サーバーへ AWS Systems Manager Session Manager を利用して接続し、ポートフォワーディングを行うことで安全にアクセスします。
また、非同期ジョブ用のRedisと、チャットや通知のようにリアルタイム反映が必要な機能のためのPub/Sub用Redisがそれぞれ1台ずつ用意されています。

課題

  • toC、toB向けのサービスがサーバー（ECS Service）単位で分割されていない
  • WAF運用の適正化
    • ブロック時のカスタムエラーページの実装

🖼️ 静的ファイル配信

現状静的ファイルを格納するS3バケットは下記4つが存在し、用途が分かれています。
公開範囲と生成元(ユーザーorシステム)でバケット単位で分割しています。
本来であれば、ユーザーアップロードとフロントエンド成果物（public バケット内の2用途）も分割したい意図がありますが、現状運用面の都合からは統合されています。今後の改善ポイントとして検討中です。

S3バケット 用途
public ユーザーアイコンやSNS投稿画像など、全世界に公開してよいパブリックな静的ファイル
ビルドしたフロントエンド成果物
private チャットなどで送信された、公開範囲を限定すべきプライベートな静的ファイル
admin public Admin用のビルド済みフロントエンド成果物
archive 以前のイベント等で使用し、アーカイブ用に静的化されたHTMLファイル

キャッシュ削除

ユーザーが投稿した画像を削除した場合でも、CloudFrontにキャッシュが残っているとURL経由で閲覧できてしまうリスクがあります。
そのため、S3からオブジェクトが削除されたイベントをトリガーに、対応するCloudFrontのキャッシュを削除（Invalidation）するLambdaが発火する仕組みを構築しています。

画像リサイズ処理

ユーザーアイコンや企業アイコンなどユーザーが投稿した画像をリサイズし、表示する場合リクエスト時にリサイズ用のパラメータがLambda側で解釈され対応したサイズに変換され画像が返却されます。
保存時にリサイズしないのは今後表示サイズが変更になった場合でも全ての画像を対応する必要がなく、運用負荷が下げられること。ユーザーが投稿した画像をこちらで無闇に修正を加えたくないことなどが理由です。

フロントエンド配信

CodeBuildでRspackビルドした成果物をS3に配置し、CloudFront経由で配信しています。
ビルド時に生成されるマニフェストファイル（assets-manifest.json）は、エントリーポイント名とハッシュ付きCDN URLの対応表になっています。Railsは起動時にこれをメモリにロードし、HTMLレンダリング時にscriptタグのURLを解決します。
また、ファイル名にコンテンツハッシュを含めることで、CloudFrontの長期キャッシュを活用しつつ、デプロイ時の即時反映を実現しています。

課題

  • publicバケット内において、フロントエンド配信リソースとユーザーアップロードオブジェクトがバケット単位で分離できていないこと。

🚀 デプロイフロー

ステージは下記3つがあります。

ステージ 用途
Source AWS CodeStar ConnectionsでGitHubと接続し、masterブランチへのpushを監視します。
発火するとmasterの最新ブランチのソースコードを取得します。
Build バックエンド(Rails)とフロントエンド(React)のビルドを担当します。
フロントエンドのビルド成果物はpublicバケットへ格納されます。
工夫点としてはECRから以前のビルドイメージを取得し、キャッシュさせることで高速化を図っています。
Deploy Codepipeline内でECS 標準のデプロイ機能を利用し、ローリングデプロイしています。
最大実行タスク%を200%にすることでユーザーの体験を損なうことなく、デプロイを実現しています。

ビルド高速化

Dockerfileを「システム依存」「Ruby依存」「フロントエンド依存」「ビルド」などの複数ステージに分割するマルチステージビルドを採用しています。
各ステージを個別タグでECRに保存し、次回ビルド時にキャッシュとして利用することで、変更のないレイヤーをスキップしています。
これにより、GemfileやPackage.jsonに変更がない場合は依存インストールを省略でき、以前は30分程度掛かっていたビルド時間がキャッシュが効いている場合10分程度と大幅に短縮しています。

課題

  • ローリングデプロイから、より安全なブルー/グリーンデプロイへの移行
  • 必要のない変更時（OpenAPIドキュメントやDesignDoc修正など）はデプロイフローを起動しない制御

🔍 ユーザー検索

ユーザー検索には Amazon OpenSearch Service を利用しています。
スプリットブレイン（ネットワーク分断によるデータの不整合）を防ぎ、可用性を高めるために3ノード構成を採用しています。
内部的には、ユーザーのプロフィールや所属の更新時にSidekiq Workerからデータを同期し、常に最新の状態を保っています。
ALBはOpenSearchダッシュボードへのルーティング用として利用しています。

👀 監視

YOUTRUSTでは監視ツールとして Sentry と Datadog を導入しています。
以前はアプリケーションエラーの検知をSentry のみに依存していましたが、ログ、インフラメトリクス、APMを含むサービス全体の観測性（Observability）を高めるため、Datadog を新たに導入しました。

  • Sentry：アプリケーションエラーの検知・スタックトレースの可視化
  • Datadog：メトリクス、ログ、APM、インフラ状態の可視化

という役割分担で併用しています。
これにより、インフラ〜アプリケーション層まで一貫した監視が可能になり、問題発生時の原因特定までのスピードが向上しました。

Datadogの導入については入社初期でお任せいただき、ブログにもまとめてありますので興味あればこちらもお読みください！ tech.youtrust.co.jp

ログ保存

ログルーターとしてECSサイドカーの Firelens を利用し、DatadogとS3の両方へ転送しています。

  • Datadog：検索性重視。保存料金が高額なため、保存期間は2週間に設定。
  • S3：長期保存用。2週間以上前のログが必要な場合は、Amazon Athena を用いて分析できる環境を整備しています。

メトリクス配信

Datadogへの通常のAPIベースのメトリクス送信では、データ反映に10分程度の遅延が発生し、障害検知にラグが生じる課題がありました。
そのため、重要なメトリクスに関しては Amazon CloudWatch Metric Streams による配信を行い、早期検知を実現しています。

課題

  • アプリケーションログの整備(ユーザーIDなど必要情報を追加)
  • モバイルアプリ監視
  • DB周りの分析環境整備
  • フロントエンドとバックエンド監視の統合
  • 自動計装以外の整備

📈 データ分析

データ分析基盤として、S3バケットへ格納された以下の2種類のデータを活用しています。
- RDSスナップショット
- ユーザーアクティビティログ: Sidekiq Workerで処理し、Fluentd経由でS3へ格納。

これらをGoogle CloudのData Transfer Service経由で Google Cloud Storage (GCS) に転送し、dbt cloud で加工した後、BigQuery で分析可能にしています。
また、マーケティング部向けなどには、Metabase を用いて簡易的なダッシュボードと分析環境を提供しています。

データ分析基盤の詳細については、先日データエンジニアが公開したブログもぜひご参照ください！
tech.youtrust.co.jp

課題

  • データパイプラインが時間制御のためデータ増加時に不具合が発生する可能性があるためイベント駆動型に切り替え
  • MetabaseのIaC化とEC2からFargateへの移行

振り返り

入社から1年が経ち、改めてインフラアーキテクチャ図をゼロから書き直してみると、入社当初には見えていなかったサービス間の細かな連携や、設計に込められた意図がクリアに理解できるようになってきました。
最初は「何がどこで動いているのか」を追いかけるだけで精一杯でしたが、日々の運用・改善・障害対応を通じてシステムの解像度が徐々に上がり、こうして自分の言葉で全体像を説明できるようになったことに、SREとしての成長をしっかり実感しています。

現在はユーザー増加を見据えたキャパシティプランニングや負荷検証にも取り組んでおり、特にアプリケーションの成長に伴って顕在化しやすくなってきた重いクエリの問題について、根本改善を進めています。
単純にインフラを増設するだけでなく、プロダクトの将来を見据えて「どのように進化させていくべきか✨」を考えながら、長期的に安定運用できる基盤を少しずつ整えているところです。

SRE2年生として迎えるこれからの1年は、こうして見えてきた改善ポイントを一つひとつ着実に前進させ、より信頼性が高く、開発者が心地よく開発できるインフラ基盤を作っていきたいと思います。
また、今回紹介した「Ver2025」は完成形ではなく、あくまで今の姿を切り取ったスナップショットです。
来年の今頃には、さらに進化した「Ver2026✨」を胸を張って公開できるように頑張ります🦾🔥