内製ツールから脱却し、Ansible でサーバ構成管理をプロジェクト横断で統一する

弊社のインフラ部門では、複数のゲームプロジェクトを横断して、アプリケーションサーバ・バッチサーバ・キャッシュサーバ・マルチプレイリレーサーバといった様々なタイプの VM サーバを管理しています。

以前はシェルスクリプトベースの内製ツールで構成管理を行っていましたが、メンテナー不在によるブラックボックス化や、各自の独自カスタマイズ、バージョン管理の欠如による運用の属人化が大きな課題となっていました。

CentOS 7 のサポート終了により、Ubuntu への移行が決まり、全体的なサーバの再構築が必要となりました。内製ツールの確実な動作が見込めない状態で、構築を行うのは難しく、ツールの刷新が必要となっていました。

• 内製ツールの改修継続
• Chef
• Ansible

メンテナーが不在になっても継続して使い続けられるか、チームメンバーが学習しやすいかという点を重視しました。内製ツールを刷新する場合も、後任のメンテナーが確保できる保証はなく、同じ問題を繰り返すリスクがありました。

内製ツールの改修は、メンテナー不在という根本的な問題が解消されないとして見送りました。Chef も候補に挙がりましたが、インフラチームに Ruby の利用者がおらず、管理対象へのエージェントのインストールも必要になることから採用を見送りました。

Ansible は YAML で設定を書けてエージェントレスで動くため、既存のチームメンバーが参入しやすく、ツールそのものの継続性もコミュニティに委ねられるという点が決め手になりました。また、同時期に Terraform の採用も進めており、組み合わせて使われる事例の多い Ansible がほぼ既定の選択肢となっていたため、他のツールを本格的に比較するには至りませんでした。

サーバ構成のコード化でバージョン管理ができるようになり、レビューが容易に行える点もありました。

プロジェクト横断で設定フォーマットを統一でき、全体の見通しが大きく改善しました。共通で変更したい項目は一箇所を修正すればよくなり、プロジェクトごとに差分を追いかける負荷が減っています。

構築時間も短縮できました。内製ツール時代は手作業での修正がたびたび発生し、サーバ構築に 1 日前後かかることもありましたが、誰が構築を行っても同じ手順で再現できるようになったことで、現在は 1〜2 時間程度で完了するケースが増えました。

また、group_vars を中心に変数を管理する運用にしたことで、設定ファイルそのものを直接編集する場面が減りました。レビューではパラメータ変更に集中できるためレビュワーの負荷が下がり、表記ミスによるシンタックスエラーも起こりにくくなっています。

内製ツールではプロジェクトごとに設定ファイルを直接配置する形でしたが、Ansible への移行にあたってはプロジェクト間の共通化を図るため Jinja2 テンプレートを採用しました。これにより、プロジェクトごとにわずかに異なっていた設定を変数として整理し直す作業が発生し、動作が以前から変わっていないかの確認に時間がかかりました。

また、CentOS 7 のサポート終了という期日に追われながら Ansible の設計を進めたため、ベストプラクティスから少し外れたファイル構成になった部分があります。動作確認の段階では少数のサーバタイプを対象にしており問題になりませんでしたが、本番対応で全タイプ分のプレイブックを揃えたとき、プレイブックをフラットに配置していたためファイルが多く並ぶ状態になりました。現在はプレイブックの命名規則を統一し、整理を済ませています。

複数のサーバやプロジェクトを横断して管理し、構成を統一したい状況に向いています。共通設定を 1 つにまとめられる点や、処理（Role）と設定値（vars）を分離できる点により、変更レビューが分かりやすくなります。

導入前に、Role とプレイブックのディレクトリ構成の設計方針を決めておくと、後から整理する手間が省けます。少数のサーバタイプで動作確認しているときは問題に気づきにくいため、本番展開を見越した全タイプでの検証や構成の方針をチーム内で決めておくことをおすすめします。

ロジックやパラメータの変更レビューの際、差分を手動で用意していますが、CI の連携を進めて自動的に差分を取得したり、事前にシンタックスエラーなどを判断できる仕組みを用意したいと考えています。

また、同時期に採用した Terraform と連携を進め、インスタンスの立ち上げからサーバの構築までを一貫で行えるような CI/CD の構築を考えています。