LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログ

LCLにおけるTerraform導入までの道のり

はじめに

この記事はLCL Advent Calendar 2020 - 3日目です。

こんにちは、バックエンドエンジニアの星野です。好きなAWSのサービスはAWS Cost Explorerです。

LCLでは2020年4月ごろからTerraformによるインフラのコード化(Infrastructure as Code)を進めております。今までインフラのコード化をしてこなかった我々が、何故インフラのコード化を必要とするのか、どのように進めているのかを紹介します。

※タイトルにTerraformと入っていますがTerraformの話はあまり出てきません

LCLでインフラのコード化が必要な理由

f:id:hosht:20201202125209p:plain
書籍Infrastructure as Codeのカバーがハゲワシなのでハゲワシのイメージです

これまでのインフラ構成

LCLでは提供しているサービスの大半がAWS上で実行されており、LCLの社内用語で「インフラ」とは主にAWSのサービスやEC2インスタンス上で動くミドルウェア等のことを指します。

歴史の長いバス比較なび格安移動のインフラはEC2インスタンス上で動くRuby on RailsやPostgreSQLクラスタが中心です。

f:id:hosht:20201202121117p:plain
DBの名前がつくEC2インスタンスの数々(一部)

過去のブログ記事にもあるようにVarnishやPgpool-Ⅱを導入することでサーバーへの負荷を大幅に軽減して、現在も安定して稼働し続けています。 しかし、5年間もの長い間インフラに大きく手を加えずに稼働し続けている弊害として、手が加わらないが故に変更方法がチームに定着せず開発メンバーの入れ替わりなども重なってメンテナンスが難しい状態になっていました。 Chefによる自動化も行われてましたがインフラの変更頻度が低い故に徐々に使われなくなっていき、手作業での変更に巻き戻ってしまっています。*1

こうなってくるとサーバー、ミドルウェアがブラックボックスになってしまい、いつか問題が発生した際に致命的なサービスダウンを招きかねません。

マネージドサービスの活用、しかし

AWSではマネージドなPostgreSQLを提供するRDSやCDNのCloudFrontを活用することでミドルウェアの運用をほとんでせずにこれまでと同等かそれ以上の恩恵に預かることができます。クラウドサービス様様です。 昨年リリースのバスツアー検索サービスではECS、RDS、CloudFront(一部)という構成になっています。

一見すると他のサービスでも同じようにミドルウェアをマネージドサービスに入れ替えるだけで完了しそうですがそれだけでは全ての問題を解決できません。 マネージドサービスの多くはAWSコンソールから作成されましたが、運用していく中で手作業による変更を繰り返さなくてはならず、これまではサーバー上でコマンドを実行していたのがWeb UIに変わっただけに過ぎません。 このままでは時間の経過により同じ問題を繰り返してしまいます。*2

今後のサービスの継続拡大も踏まえてインフラの開発、運用方法を見直す必要性を感じていました。

Terraformの導入

そこで、LCLでは宣言的なインフラを実現するツールとしてTerraformの導入を進めております。 Terraformについては日本語でも紹介の記事がたくさんあるのでそちらに譲ります。

www.terraform.io

書籍やネット上での事例を調査する中で、インフラをコードにすることで既存のソフトウェア開発のプラクティスをインフラ開発にも適用でき、前述の課題を解決できると判断しました。

類似ツールとの比較検討

AWSではCloudFormation、CDKなどTerraform以外にも宣言的なインフラを実現するツールがあります。*3 最初に簡単なデモを披露して軽くディスカッションした結果、Terraformに決まりました。 決定にあたり明確な強い理由があったわけではありませんが、ゼロからの導入なため、うまく行かなかった場合でも早いタイミングで別のツールに切り替えられる目論見がありました。 Terraformに限らずチーム全体で使っていくツールを選ぶ際は、トップダウンでの決定よりも実際に利用するエンジニアの意見を尊重するのが重要と考えています。

小さく始める

いきなりメインのサービスに導入してしまうと、上手くいかなかった際にツールに非はなくてもネガティブなイメージを持たれ、全社的な導入に影響を及ぼしてしまいます。 まずは社内向けの小さなプロジェクトから使い始めて、ツールの基本的な使い方やチームで開発を回すためのノウハウを貯めていきました。

幸い2019年9月にTerraform CloudがGAになっていたのでチーム開発のための基盤構築はほとんど不要でした。 Terraform CloudについてはTerraform Cloud自体をTerraformで管理したりとフルに活用しています。

開発体制が整ってきたところで既存のインフラをTerraformで作り直すプロジェクトを始めており、これは現在も継続中です。

チームでのインフラ開発

最後にインフラの開発をチームに浸透させるための取り組みを紹介します。

ペアプログラミング/モブプログラミング

Terraformでのインフラ開発の多くをペアプログラミングやモブプログラミングで行っています。Terraformに詳しいメンバーだけで開発を進めていると問題が別の手法に移っただけになってしまい、それは避けなければなりません。Terraformのオンボーディングや設定一つ一つを話し合いながら手を動かすことで特定のメンバーに知識が偏るの防ぎ、チーム一丸でインフラの開発を進められるように細心の注意を払っています。

GitHub上でのレビュー体制

インフラがコード化されていることで変更をGitHubのPull Requestでレビューできるようになります。

ペア作業が推奨とはいえ常に開発者のスケジュールが揃うわけではありません。ペア作業による同期的な開発とPull Requestベースの非同期な開発を組み合わせることでスムーズな開発体験を実現できています。

終わりに

LCLでのインフラのコード化、Terraform導入は始まったばかりです。 本丸であるEC2インスタンス郡にはまだ手をつけられていませんが、そう遠くない日に向き合える手応えを感じています。

この記事がインフラのコード化導入の一事例として役立てば幸いです。

*1:Chefが良くないツールというわけではありません。Chefは依然として素晴らしい自動化ツールで運用体制の問題です

*2:別の問題として混沌としたVPCやいつ作られたか不明な謎リソースなど枚挙にいとまがありません

*3:KubernetesもありますがLCLでは開発チームがECSに慣れていたため候補から外れました