インフラ構成概要
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 のためのメッセージキューとして採用。 |
Wantedly の各マイクロサービスにおける主要なデータストアは、AWS の リレーショナルデータベース (RDB) である RDS for PostgreSQL が多く採用されています。 また、一部の高負荷な RDB は今後のパフォーマンス、スケーラビリティを考慮して Aurora for PostgreSQL を採用・移行しました。 PostgreSQL 互換エディションを利用しているため基本的にはすべての RDB が PostgreSQL であると考えて構いません。
キャッシュのためのデータストアでは 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 (コード) で行います。
最終更新 8mo ago