はじめに
こんにちは、TIGの森です。
IaCを使うにあたって重要なのは、単に各言語を使いこなしてインフラ環境をプロビジョニングするだけでなく、使用するIaCがどのような設計思想・指導原理を持っているかを把握し、明確な目的意識を持って実装する事です。
今回はインフラエンジニアとして経験したAnsibleを用いたアプリ関連の設定ファイル管理における問題点と、その解決方針について詳述します。
背景
Futureのあるプロジェクトではサーバの設定管理はAnsibleでほぼ実装していました。
それまではネットワークやOSなどの基本的なサーバのプロビジョニングはインフラチームがAnsibleで独自に実施しており、アプリチームは基本的にIaCはいじれないようにしていました。
ある日、一部のアプリの設定もAnsibleに埋め込んでほしいとの依頼を受け、特に何も考えずにインフラ側のサーバの管理設定のAnsibleの中に安請け合いして組み込んでしまいました。
問題発生
結論をいうと、これは対応としてはいまいちでした。
デプロイの際に問題が出たとかではないのですが、アプリ側の設定変更の頻度はインフラ側のそれと比べて遥かに多く、インフラ側の対応が高頻度で必要となり、結果としてオペレーションコストが高くついてしまったのです。
Ansibleの実行権限を不用意にインフラ以外のチームに移譲するのはリスクが大きいですし、結局少ないインフラチームがアプリ側の設定変更の依頼を受けて毎回Ansibleを流す、という非効率なオペレーションを脱却しきれないまま開発が進んでしまいました。
問題になっているのはなにか
なぜこのアプローチがうまく機能しなかったかというと、それまでAnsibleを利用する目的はプロビジョニングがメイン(更新頻度低)であったのにもかかわらず、アプリの設定ファイル(更新度高)もAnsible管理に入れてしまったため、従来の目的とずれるIaC運用を実施してしまったからです。
この状態が続くと、インフラチームのオペレーションだけでなくアプリチームの気軽に設定を変えたいという要望が満たせずアプリチーム側も開発へのストレスが溜まってしまいます。
解決案検討
問題は特定できたのであとは解決策を考えます。
やはりアプリチームにも設定が変更出来るようにはしたいですが、過剰な権限を移譲するのはリスクの観点から好ましくないです。したがって、あくまでアプリ関連の設定だけ操作できて、それ以外のサーバ内の操作はさせないという方向性で考えていきます。
案1: アプリ設定のみ操作可能なAnsibleサーバとリポジトリを作成する
簡単な解決策として、アプリ設定の箇所のみアプリチームが操作できるAnsibleを別途用意して、アプリチームが簡単にデプロイをできるようにする、というのがあります。
- メリット: 既存のコードの使い回しが可能なので、実装が簡単。
- デメリット: アプリチーム側でAnsibleの環境構築の工数や学習が必要になるなど、アプリチーム側での作業・学習コストが必要。
案2: アプリ設定更新向けジョブの作成
もう一つ考えられるのが、アプリケーション設定の更新が出来るジョブを作成するアプローチです。
変更頻度の高い設定箇所はいっそのこと別途ジョブで管理してしまうようにすれば、アプリチームもサクッといじれるような柔軟性が確保できます。
- メリット: Ansibleに比べて学習コストが少なく済む場合が多い。
- デメリット: 別途ジョブの準備・メンテナンスの工数がかかる。サーバの設定が一括で管理できなくなる。
以上の2案が考えられると思うのですが、それぞれメリットとデメリットもあるので、ケースバイケースで検討するのがよいかと思います。
学びと今後の展望
特にインフラチームとアプリチームが分かれている大規模案件だと、どうしてもサーバ関連の設定ファイルはインフラチームのみが管理すべき必要があると思われがちで、私も基本はそれに賛成です。
しかし、アプリ側の要求に従って頻繁にアプリ向け設定を更新する必要があったり、パラメータを変えてテストがしたいなどという場合があれば例外的に一部アプリチームに設定ファイル更新の権限を移譲する、というのも手ではあるかと考えています。
このあたりの構成の検討は難しいですが、判断基準の一つとして念頭に置きたいのはやはり多くのIaCの教科書でも言及されているとおり、まずはIaCを用いる目的に立ち返ってみることです。
現在触れているIaCの主目的はプロビジョニングなのか、運用なのか、復旧なのか、etc..を明確にしつつ、その目的のために変更される余地のある箇所とない箇所、更新される箇所があるとしたらどのくらいの頻度かなどの一連の流れまで予め考えておくとそれ以降の開発が楽になるかと思います。
さいごに
単にオペレーションの関係上、他のチームもサーバの設定変更ができる柔軟性のある構成にしたい、というだけのシンプルな話で閉じられそうではありますが、普段あるチームが管理している箇所を他チームが更新したい要望は他のケースでもあると思います。
その際に全体として最適な構成は何だろう？と立ち止まって一旦考えるプロセスを挟むのは重要で、今後色々と応用は効くのでないかと思います。