インフラ構成概要

Wantedly のシステムを構成する各マイクロサービスは全て Kubernetes クラスタ上で動いていますが、この Kubernetes クラスタはパブリッククラウドである Amazon Web Service (AWS) 上で動いています。またシステムに必要なコンポーネントとしては AWS だけではなく、同じくパブリッククラウドである Google Cloud Platform (GCP) も利用しています。

この章では Wantedly のマイクロサービスにおける代表的なインフラストラクチャの構成を説明し、どのようなミドルウェアやクラウドサービスを利用しているかを解説します。

構成図

構成図は次のとおりです。

各コンポーネントの役割は次のとおりです。

コンポーネント	サービス名	プロバイダー	説明
データストア	RDS for PostgreSQL	AWS	主要なデータベースとして使われる RDB。ほとんどのマイクロサービスで採用。
データストア	Aurora for PostgreSQL	AWS	主要な RDB のうち、特に負荷が高いマイクロサービスで採用。
データストア	ElastiCache for Redis	AWS	各マイクロサービスでキャッシュ用 KVS として採用。また、Rails では非同期ジョブ (Sidekiq) のためのメッセージキューとして採用。
データストア	Elasticsearch on k8s	-	各マイクロサービスの検索エンジンとして採用。
データストア	Cloud Datastore	GCP	一部のマイクロサービスのデータストアでのみで採用される KVS。
データウェアハウス	Google BigQuery	GCP	データ分析環境。ログ、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	GCP	Event-Driven Architecture のためのメッセージキューとして採用。

コンポーネント解説

データストア

RDB

Wantedly の各マイクロサービスにおける主要なデータストアは、AWS の リレーショナルデータベース (RDB) である RDS for PostgreSQL が多く採用されています。 また、一部の高負荷な RDB は今後のパフォーマンス、スケーラビリティを考慮して Aurora for PostgreSQL を採用・移行しました。 PostgreSQL 互換エディションを利用しているため基本的にはすべての RDB が PostgreSQL であると考えて構いません。

KVS

キャッシュのためのデータストアでは ElastiCache for Redis が多く採用されています。 また、非同期ジョブの構成に Ruby on Rails の Sidekiq をよく使っていることもあり、そのメッセージキューとしても ElastiCache for Redis が使われています。

一部のマイクロサービスでは、主要なデータストアに Google の KVS である Cloud Datastore を採用しているものもあります。

検索エンジン

検索エンジンとしては Elasticsearch を採用し、 Kubernetes 上で動かしています。 過去は Kubernetes ではなく EC2 上で Elasticsearch クラスタを組んでいたこともありました。

データウェアハウス

データ分析基盤として Google BigQuery を採用しています。各マイクロサービスのアクセスログやイベントログがリアルタイムで連携されるほか、データベースやマスタが daily または hourly で連携されています。 詳しくは データ基盤入門 を参照してください。

メッセージキュー

Ruby on Rails の Sidekiq を使うために ElastiCache for Redis を採用しています。 最近では 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