DX事業本部インフラの3年分の進化 (2019 ~ 2022)

お疲れさまです。SREの西田和史(@k_bigwheel)です。僕が所属するDX事業本部の開発基盤グループは主にインフラが安定して高いパフォーマンスで動くことに責務を持っています。今DX事業本部には3つの事業部があり、その中ではイエウール、ヌリカエ、ケアスル介護などのサービスを展開していますので、僕らはそれらのだいたい10サービス前後のインフラを日々増築・改善しています。

僕がSpeeeにジョインしたのが3年前の2019年11月なのですが、それからDX事業本部のインフラは様々なことが進化しました。3年前から変わらず残っているインフラコンポーネントは永続化層¹ぐらいといえる程です。ここではその差分を振り返ってこんな良いインフラになったぞ！という部分を書いていきたいと思います。

レガシーインフラの脱却

いきなりですが、3年前に使っていたツール・サービスと今使っているツール・サービスの対応表が以下です。

種別	廃止されたツール	移行先
コンピューティング	EC2インスタンス AWS オートスケーリング ECS	EKS
インフラ構成管理	手動管理 CloudFormation	Terraform
インフラ構成管理	itamae	docker
デプロイ	capistrano	docker + Argo CD
監視	statsd zabbix	datadog
ログ収集	fluentd server	cloudwatch logs
アプリケーションサーバ	unicorn	puma
webサーバ	nginx	AWS (ALB + CloudFront + WAF)
CICD/タスクランナー	jenkins CircleCI	GitHub Actions
秘匿情報管理	なし(踏み台サーバに直置き)	AWS SSM Parameter Store
その他	踏み台サーバ	EC2 Instance Connect DBのpublicly accessible化

その結果、3つの事業部の10以上のインフラがだいたい以下の構成になりました。

個別に振り返っていきます。

コンピューティング

種別	廃止されたツール	移行先
コンピューティング	EC2インスタンス AWS オートスケーリング ECS	EKS

3年前はDX事業本部のインフラは結構カオスな状態でした。というのも、以下が混じり合っていたためです。

手で作られたEC2インスタンス
手で作られたEC2オートスケーリング
CloudFormationで管理されたEC2インスタンス
CloudFormationで管理されたECSクラスタ
試験的に手で作られたEKSクラスタ

今はすべてEKSクラスタへ統一されています。
ECSではなくEKS(Kubernetes)にした理由ですが、実は僕の入社時点でKubernetesの利用を増やしていくことがだいたい決まっていたため僕はそこの意思決定には参加していませんでした。

なので、そうした理由は説明できないのですが、3年EKSでやってみてECSと比較してのメリデメを語ると、メリットは知見の多さや拡張性の高さ、ここでの経験が今後も長く使える、AWS以外のインフラでも活用できる、といったことになります。これはKubernetesというOSSベースであること、ECSというクローズドなサービスでないことからくる利点ですね。逆にデメリットもECSよりEKSのマネージド領域が狭いことから来ていて、EKSのほうがECSより利用者が見る必要のある領域が多いのでより手がかかります。より具体的に言うなら、ECSは困った時にAWSサポートへ投げて解決できる可能性が高いです。

蛇足ですが、3年前と比べるとEKSは便利なサービスになりました。利用開始当初はAWSマネージメントコンソールで見ることができたり操作できることがほとんどなくて頼りないサービスでしたが、最近では中にはいっているpodの状態を見ることができるようになったりオペレーターをAdd-onという名前で一部管理できるようになったりしています。

種別	廃止されたツール	移行先
インフラ構成管理	手動管理 CloudFormation	Terraform

脱CloudFormationは、従来CloudFormationで管理していたものをTerraformでimportするパターンと、EKSへ移行してCloudFormation管理のものを削除するパターンの2種類があったのですが、前者のimportパターンが実はとても大変でした。これだけ全部終わるまで1.5年ぐらいかかったのですが、一番大きな理由はCloudFormationで作ったリソースを残したままCloudFormationスタックを消す、という操作が簡単安全にできないためでした。

このCloudFormationスタックだけ消す方法は調べると出てくるのですが、AWS公式でのドキュメントではなく、万が一にも間違って消せないリソースで試すことには大きな心理的ハードルがありました。二番目に大きな理由はterraformで既存のリソースをimportして組み込む作業が大変だったことです。importのやり方がリソースごとに違い、かつimport後のリソースの定義は結局自分で書く必要があるため100以上のリソースの移行は単純に手間がかかりました。

種別	廃止されたツール	移行先
インフラ構成管理	itamae, ansible	docker

EC2インスタンス内のプロビジョニングにはitamaeとansibleを使っていたのですが、これはdocker化することでimage内に閉じ込めることに成功しました。これによりitamae, ansibleは完全に廃止できました。ただ、itamae/ansibleとdockerでのプロビジョニング方式には大きな差分があるため、移行期にはかなり苦労したことを覚えています。

CICD/タスクランナー

種別	廃止されたツール	移行先
CICD/タスクランナー	CircleCI	GitHub Actions
CICD/タスクランナー	jenkins	GitHub Actions Self Hosted Runner

CICDは概ねCircleCIを使っていたのをGitHub Actionsへ移行しました。正確にはEKS化に合わせてCICDを作り直す必要がありそこでCircleCIではなくGitHub Actionsにした結果、事業本部内の過半数がGitHub Actionsになり、また会社全体でもGitHub Actionsへ移行する流れになったので全面的に移行した形です。ここはあんまり苦労したつもりはなくて、うまくトレンドに乗れた形でした。

大変だったのがJenkinsでした。何が大変だったかというとJenkinsはVPC内にサーバーがあったことで、それ前提のタスクが多くあったことです。例えばDBへ直接接続してのSQL実行などで、これは通常のGitHub Actionsから行うことはネットワーク・トポロジー上困難でした。そこで助けになったのがGitHub Actionsを自分たちが用意したインスタンス上で実行できるSelf Hosted Runnerという仕組みと、それをKubernetes上でよしなにプロビジョニングしてくれるactions runner controllerというOSSでした。このお陰で従来のJenkinsと同じくVPC内でタスクを実行することができるようになり、従来からそれほど大きく形を変えずにタスクを実行できるようになりました。

デプロイ

種別	廃止されたツール	移行先
デプロイ	capistrano	docker + ECR + Argo CD (一時期kubectl apply)

デプロイに使っていたcapistranoは完全に廃止しました。
capistranoはすでに存在するインスタンスへSSH接続を行い、そこでビルド・プロセスの停止・アーティファクトの展開・プロセスの開始をするようなモデルのツールです。コンテナモデルに移行するとインスタンスがなくなりアーティファクトの展開などの必要もなくなるので、そのあたりのトラブルや考慮事項はまったくなくなりました(過去にはビルド中にメモリを食いつぶしてサーバーがダウンするようなことがありました)。

それに変わるデプロイ方法は、最初はGitHub Actions上でkubectl apply をやっていたのですが、2020年頃前々職の後輩に「Argo CDってのが来てるらしいっすよ」と教えてもらい少しの試験の後に導入しました。するととても感触が良かったのでそのあとすべてのデプロイ方法をArgo CDによるGitOpsへ変更しています。

この選択は大正解で、Argo CDは2020/09現在CNCFのTechnology RadarでもADOPTの位置にありKubernetesのデプロイツールとしてデファクトスタンダードになっています。

監視

種別	廃止されたツール	移行先
監視	statsd zabbix	datadog

各サーバーのヘルスチェックやCPU/メモリーメトリクスの取得にstatsdやzabbixを使っていたのですが、すべてをdatadog化しました。正確に言うと全社的にdatadogがすでに導入されていたので、やったのはstatsdやzabbixの設定をdatadogへ移したり不要なものを削除したのみです。
これにより管理するサーバー数を削減でき、監視設定をterraformで管理できるというメリットも生まれました。

ログ収集

種別	廃止されたツール	移行先
ログ収集	fluentd server	cloudwatch logs

ログ収集はfluentd (td-agent) + ec2にインストールしたfluentd serverという構成だったのですが、これをkubernetesの各ノードへdaemonsetを利用してfluentdポッドを稼働させる方式に変更しました。
この後、2022/04辺りにfluentd → fluent-bitの移行をしています。これも非マネージドなサーバーインスタンス管理が減り、かつログ検索などがしやすくなってよかったです。

一方で、標準の設定では各podの標準出力しかcloudwatch logsへ転送されないため、標準出力以外のログも収集したいシステムではちょっとした混乱が発生したりもしました(婉曲表現)。その辺りをよく確認せず進めたことが原因なので、ちゃんと確認しつつ気を配って移行すればfluent-bitなどを使うことは何ら問題ないと思います。

アプリケーションサーバ

種別	廃止されたツール	移行先
アプリケーションサーバ	unicorn	puma

これはインフラの改善というよりアプリケーション側なのですが、2年前時点でRailsでは非推奨になっていたunicornをpumaへ移しました。事業本部内でunicornとpumaが混じっている状態が解消したのでこれもやってよかったです。

webサーバ

種別	廃止されたツール	移行先
webサーバ	nginx	AWS (ALB + CloudFront + WAF)

ELBとアプリケーションサーバの間によく挟まっているnginxを廃止しました。
これは賛否両論あると思うのですが、個人的には数年以上前からAWSの環境でnginxやapacheを使うことに疑問を持ってました。というのは、nginxのようなwebサーバが担っている機能は

権限管理
ルーティング設定

が主だと思うのですが、この両方ともALB, CloudFront, WAFで代用できるためです。
その一方でnginxやapacheのコンポーネントとしての管理コストはかなり高いため、割りに合っていないと感じていました。廃止後ですが、今の所一度も困ったことはありません。一方でnginxの設定の複雑性やバージョンアップから開放されたことによるコスト減は劇的でした。

秘匿情報管理

種別	廃止されたツール	移行先
秘匿情報管理	なし(踏み台サーバに直置き)	AWS SSM Parameter Store

従来は踏み台サーバ上のcapistranoからデプロイしていたため、秘匿情報はそこに置かれていました。
現在はSSM Parameter Store上のパラメーターとして保存されています。これはたくさんの利点があります。代表的な利点を挙げると

aws kmsで暗号化でき、複合できるユーザーも制限できる
github actionsなどから情報へアクセスしやすい(awscliのコマンドで取得できる)
external secrets operatorなどでkubernetes内のsecretsへ同期できる
マネージドなサービスなので管理コストが最小限
AWSマネージメントコンソールに統合されていて使いやすい

などがあります。

その他

種別	廃止されたツール	移行先
その他	踏み台サーバ	EC2 Instance Connect DBのpublicly accessible化

踏み台(bastion)サーバも廃止しました。これも以前からAWS環境では必要性が疑問であったためです。
詳細は過去にブログへまとめているのでこちらにどうぞ bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言 - kbigwheelのプログラミング・ソフトウェア技術系ブログ。

まとめ

というわけで、この3年間でSpeee DX事業本部のインフラの変わったところを書きました。書いていて色々やったなあと感慨深くなりましたが、まだまだやりたいことはたくさんあります。例えばカナリアデプロイ、自動的なUXテスト、デプロイの高速化など、開発を安定させつつ加速させる手段のアイデアはたくさんあって手が足りていません。

DX事業本部開発基盤グループは一緒にインフラを改善してくれる仲間を募集しています。もし興味を持っていただいた方は以下で僕のカジュアル面談を公開しているので、お気軽にご連絡ください💁

Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！