Wantedly Engineering Handbook
🎧 Podcast
🍿 YouTube
🛋 Blog
💬 Twitter
検索…
Wantedly Engineering Handbook
まえがき
第一部:開発チームへの案内
技術とアーキテクチャ
プロダクト概要(未執筆)
開発チームの構造
コミュニケーションの全体
ドキュメンテーション(未執筆)
カレンダー
障害対応の心構え
第二部:技術領域への案内
System
Application
Infrastructure
プロダクト開発のための Kubernetes 入門
インフラ構成概要
リリース・デプロイ戦略
SaaS を活用する:New Relic, Honeybadger, Datadog
Data
開発プロセス
開発ツール
おわりに
ロードマップ(未執筆)
Handbook の書き方
コントリビューター
付録
社内用語集
主要なGitHubレポジトリのリスト
今後の挑戦・未解決イシュー
プロダクト開発組織のバリュー
採用についての考え方
GitBook
上で動作しています
インフラ構成概要
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
コンテンツ配信
ネットワーク
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 からコントロールされています。
DNS には DNSimple と AWS の Route53 の2つを利用しています。
インフラの構成管理
これらのクラウドサービスの構成や設定は、Terraform というツールを使ってすべてコードで管理しています。 これにより、インフラチームに限らず全ての開発者がコードを書いてインフラリソースの追加を行えるようになりました。インフラリソース追加・削除・変更の依頼は Issue (文章) ではなく、Pull Request (コード) で行います。
Terraform のコードは
wantedly/wantedly-terraform (internal)
で中央集権的に管理されています。
話を聞きに行きたい
Slack:
#infra
前
プロダクト開発のための Kubernetes 入門
次
リリース・デプロイ戦略
最終更新
3mo ago
リンクのコピー
目次
構成図
コンポーネント解説
データストア
データウェアハウス
メッセージキュー
ネットワーク
インフラの構成管理