インフラ構成概要

検索…
インフラ構成概要
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​
前
プロダクト開発のための Kubernetes 入門
次
リリース・デプロイ戦略
最終更新 1mo ago
リンクのコピー
概要