インフラ構成概要
ウォンテッドリーのシステムを構成する各マイクロサービスは全て Kubernetes クラスタ上で動いていますが、この Kubernetes クラスタはパブリッククラウドである Amazon Web Service (AWS) 上で動いています。またシステムに必要なコンポーネントとしては AWS だけではなく、同じくパブリッククラウドである Google Cloud Platform (GCP) も利用しています。
この章ではウォンテッドリーのマイクロサービスにおける代表的なインフラストラクチャの構成を説明し、どのようなミドルウェアやクラウドサービスを利用しているかを解説します。
構成図
構成図は次のとおりです。
各コンポーネントの役割は次のとおりです。
データストア
Aurora for PostgreSQL
AWS
主要なデータベースとして使われる RDB。2024年以前のマイクロサービスについても、負荷が高いものは Aurora に移行済み。
データストア
RDS for PostgreSQL
AWS
2024年以前のマイクロサービスで採用。
データストア
ElastiCache for Valkey
AWS
各マイクロサービスでキャッシュ用 KVS として採用。また、Rails では非同期ジョブ (Sidekiq) のためのメッセージキューとして採用。
データストア
Amazon OpenSearch Service
AWS
各マイクロサービスの検索エンジンとして採用。
データストア
Elasticsearch on k8s
-
各マイクロサービスの検索エンジンとして採用。 Amazon OpenSearch Service への移行を進めている。
データストア
Cloud Datastore
Google Cloud
一部のマイクロサービスのデータストアでのみで採用される KVS。
データウェアハウス
BigQuery
Google Cloud
データ分析環境。ログ、DBのデータを格納。
コンピュート
EC2
AWS
Kubernetes を構成する Master / Node のコンピュート
ネットワーク
ALB
AWS
Kubernetes Ingress を構成するロードバランサー
ネットワーク
CloudFront
AWS
コンテンツ配信
ネットワーク
Web Application Firewall
AWS
攻撃リクエストからアプリケーションを保護するファイアウォール
ネットワーク
Route53
AWS
DNS サービス
ネットワーク
DNSimple
DNSimple
DNS サービス
ストレージ
S3
AWS
コンテンツを格納するオブジェクトストレージ
メッセージキュー
Cloud Pub/Sub
Google Cloud
Event-Driven Architecture のためのメッセージキューとして採用。
コンポーネント解説
データストア
RDB
ウォンテッドリーの各マイクロサービスにおける主要なデータストアは、AWS の リレーショナルデータベース (RDB) である Aurora for PostgreSQL または RDS for PostgreSQL が多く採用されています。 Aurora と RDS の使い分けは以下の通りです。
2024年以降のマイクロサービスでは原則として Aurora for PostgreSQL を採用しています。
2024年以前のマイクロサービスでは主に RDS for PostgreSQL を利用していましたが、負荷の高いものについては Aurora for PostgreSQL に移行済みです。
PostgreSQL 互換エディションを利用しているため基本的にはすべての RDB が PostgreSQL であると考えて構いません。
KVS
キャッシュのためのデータストアでは ElastiCache for Valkey が多く採用されています。 また、非同期ジョブの構成に Ruby on Rails の Sidekiq をよく使っていることもあり、そのメッセージキューとしても ElastiCache for Valkey が使われています。
一部のマイクロサービスでは、主要なデータストアに Google の KVS である Cloud Datastore を採用しているものもあります。
検索エンジン
新規に導入される全文検索は基本的に Amazon OpenSearch Service で運用する予定です。
ただし、2026年以前に導入された検索エンジンの大部分はまだ Kubernetes 上の Elasticsearch で動いています。これらについても順次 Amazon OpenSearch Service に移行していく予定です。
さらに古い時代には Kubernetes ではなく EC2 上で Elasticsearch クラスタを組んでいたこともありました。
データウェアハウス
データ分析基盤として BigQuery を採用しています。各マイクロサービスのアクセスログやイベントログがリアルタイムで連携されるほか、データベースやマスタが daily, hourly, または準リアルタイムで連携されています。 詳しくは データ基盤入門 を参照してください。
メッセージキュー
Ruby on Rails の Sidekiq を使うために ElastiCache for Valkey を採用しています。 最近では Sidekiq の他に、マイクロサービス間の非同期メッセージングに Cloud Pub/Sub と Publisher/Subscriber アプリケーションの自前実装を採用することが多くなりました。
ネットワーク
コンテンツ配信（CDN）は AWS の CloudFront を利用しています。そのバックエンドにはオブジェクトストレージである S3 か、もしくは画像処理系のマイクロサービスのロードバランサーを配置しています。
アプリケーションへのアクセスは AWS の Application Load Balancer (ALB) を 利用しています。この ALB は Kubernetes のリソースである Ingress からコントロールされています。
セキュリティ対策として AWS WAF(Web Application Firewall) が一部導入されています。脆弱性を突いた攻撃リクエストやボットによる大量アクセスを遮断し、アプリケーションを保護する役割です。
DNS には DNSimple と AWS の Route53 の2つを利用しています。
インフラの構成管理
これらのクラウドサービスの構成や設定は、Terraform というツールを使ってすべてコードで管理しています。 これにより、インフラチームに限らず全ての開発者がコードを書いてインフラリソースの追加を行えるようになりました。インフラリソース追加・削除・変更の依頼は Issue (文章) ではなく、Pull Request (コード) で行います。
Terraform のコードは wantedly/wantedly-terraform (internal) で中央集権的に管理されています。
インフラの変遷
現在の構成に至るまでの歴史については、インフラ構成の変遷 を参照してください。
話を聞きに行きたい
Slack: #infra
最終更新