構成情報管理SaaSプラットフォームのConfigがプライベートベータを開始

Configは、構成ファイル管理を目的とする、新しいSaaSサービスだ。Bien David氏が2017年に創立した同社は、システムやアプリ、モジュール、環境、サーバインスタンスが使用するコンフィギュレーションの保管とアクセスの簡略化を目標とする。InfoQはConfigを運営するチームに、同サービスが解決する3つの問題について詳しい説明を聞くことにした。

Configプラットフォームはパブリックとプライベートいずれの環境でも動作し、INI、XML、JSON、YAML、TOMLなどの構成ファイルに記述されたプロパティに対応する。バージョン管理や変更レビューのワークフロー、検索などの機能を備え、継続的インテグレーション(CI)およびデプロイメント(CD)をサポートする。

Configは現在プライベートベータで、複数の価格プランが用意されている。ユーザの追加、webhook通知などの機能、オンプレミスサポート、あるいはシステム毎のアプリ追加などによって価格が上昇する。

現在の構成管理にはどのような課題があるのだろうか？このサービスは、チームが現在運用しているソリューションとはどのように動作するのだろうか？InfoQはBien David氏にこれらを質問した。

InfoQ: 構成ファイルの管理に関して、開発者やシステム管理者が現在直面している問題とは、おもにどのようなものなのでしょう？

Config: 大きな問題として挙げられるのは、さまざまな環境の構成ファイルを簡単に管理する方法です。システムの構成ファイルはどのサーバでも同じという訳には行きません。構成ファイルはサーバイメージやrsync対象の一部分なのです。開発から運用に移行する場合のアプリと同じように、構成ファイルも環境によって変わります。

システムの状況やジョブ機能によって抱える問題は違いますので、私の説明がすべてに当てはまる訳ではありませんが、ここでは3つのグループ - プログラマ､システム管理者、マネージャが直面する問題について説明したいと思います。

まず、プログラマ。複数の環境(ローカル、Dev、QA、ステージング、運用)とインスタンス(クラスタ、リージョンなど)に展開する必要のあるアプリケーションのある場合、すべてを確実に同期する手段が問題になります。すべてのサーバに共通する設定エントリを新たに追加するには、どうすればよいのか？環境特有の設定を追加するには？これに関連して、構成ファイルの保管場所という問題もあります。

プログラマが新たなアプリケーション開発に着手する時、特に不慣れなフレームワークを使用する時には、コンフィギュレーションは優先順位が高くないことから、特殊なライフサイクルを巡ることになります。最初はハードコードで始まり、定数に変更され、コンフィギュレーション値に移動し、外部の構成ファイルやシステム環境変数に納められます。作成された構成ファイルは、最終的には環境値でオーバーライドされるようになるか、あるいは集中的なコンフィギュレーションに移行されます。この最終段階においても、環境によって異なるコンフィギュレーションを管理するための、簡単で標準的な方法というものはありません。手作業やコンフィギュレーションの同期に頼っているのが現実なのです。アプリケーションフレームワークないしコンフィギュレーションライブラリに依存したコードがまだ残っています。アプリケーションが増え、使用するサーバが増え、チームが大規模化し分散型になるにつれて、問題は増える一方です。

次に、これらの構成ファイルをどこに保存するかという問題です。サーバ自体に置く、ソースコードリポジトリの一部として保管する、別のコンフィギュレーションリポジトリに保管する、集中型の構成サーバに保存する、などの方法があるでしょう。どこに置くにせよ、共通な値と環境特有の値がマスタコピーに正しく適用されていることと、適切なロケーションに配置されることを確実にすることが必要です。また、一部の企業ではステージングおよび運用環境をロックダウンしていて、構成変更のプロセスに要する時間が長くなっているという事実も忘れてはなりません。

システム管理者。システム管理者は構成ファイルの問題を、プログラマとは違う視点で見ています。まず最初に、OSとシステム構成を管理しなくてはなりません。新しいサーバやデスクトップ、インストールされている標準ソフトウェア、必要な環境やサーバ固有のコンフィギュレーションをプロビジョニングする必要があります。第2に、ロックダウンされた環境でのアプリケーション構成に気を配らなくてはなりません。カスタムアプリケーションの場合には、ドキュメントが不足していたり、オンラインヘルプが用意されていなかったりするのが普通です。最高のシナリオとして、アプリケーションの開発者がまだ会社に在籍していれば、手を貸してくれるかも知れません。

マネージャ。めったに議論の対象にならない第3のグループは、運用サーバのスムーズな運用に気を病むテクニカルマネージャたちです。彼らは運用上の問題を迅速に解決し、さらには防止しなければなりません。アプリケーションとサーバは、少なくとも理論上はすべて同じなので、環境毎に違うのはコンフィギュレーションです。ですから、ある環境でうまくいっているものが他では動作しない場合、まず最初に確認する対象のひとつです。

次のような経験をしたことがありますか？運用システムでトラブルが起きているため、テクニカルマネージャが慌てふためいています。コンフィギュレーションとログを確認したいのですが、アクセス権がありません。古いアプリケーションなので開発者はもういません。ですから、システム管理者を探します。システム管理者はアプリケーション構成に不慣れなので、一緒に構成ファイルを探し出し、他の構成ファイルと比較します。その内容を確認するため、手に入るドキュメント類を利用します。もっとよい方法があるはずです。

InfoQ: ユーザがまだ気付いていないような問題は何かありますか？

Config: YAGNI信者と言えるプログラマは、私自身も含めてたくさんいます。構成ファイル管理のソリューションに標準的なものがなければ、使用しているアプリケーションプラットフォームやフレームワークでやりやすいような、簡単な方法で管理することになります。構成ファイルはあまり重要視されていないことが多いので、アプローチもさまざまです。開発中はこの方法で問題ありませんが、プロジェクトの完成度が高まるにつれて問題になります。さまざまなサーバ上のたくさんのアプリケーションを、それぞれ独自の方法で管理しなくてはならないのです。

システム管理者にとって、構成管理は主要業務のひとつです。IaCの普及はその証です。彼らが問題の所在を知っていても、企業の判断によって公開が妨げられている場合もあります。

最後に述べておきたいのは、使い捨て(disposable)アプリケーションとコンテナへの移行です。新しいアプリケーションを新たなコンテナで簡単に起動できれば、心配しなければならないのは設定だけになります。この傾向は、構成ファイルの管理を非常に重要なものにします。

InfoQ: 既存のソリューションの状況において、Config開発のヒントを得たギャップはどのような部分にあったのですか？

Config: よい質問ですね。構成ファイルには、簡単な解決策の見つからない問題があります。StackOverflowの古い質問には明確な回答がありませんし、2017年のブログ記事にも同じような問題に関する不満が見られます。AIの時代になっても、この比較的単純な問題は解決していません。
 
では、すべての環境のすべてのアプリケーション構成ファイルを、どうやって管理すればよいのでしょう？そのソリューションが今ここにあります。Configを導入することで、構成ファイルのソース管理への保存と、集中的な構成サーバからのアクセスの間のギャップを埋めることができるのです。Configを、使いやすいWebインターフェースを備えた、構成ファイル専用のソース管理システムだと考えてください。デプロイ時の依存性解決でランタイム時のオーバヘッドを回避する一方で、オンデマンドなコンフィギュレーション生成機能によって、集中化された実行時ソリューションのメリットも享受できます。
 
手作業 <-> ソース管理 <-> Config <-> マイクロサービス <-> 集中型サーバ <-> IaC
 
それぞれの長所と短所については触れませんが、Configをこれら既存ソリューションと比較してみたいと思います。
 
手作業 vs. Config - 小さなアプリケーションを１、２台のサーバで運用するのであれば、手作業でも間に合います。Configが必要になる理由はただひとつ、この小さなアプリケーションが多数ある場合です。Configをアプリケーションインベントリとして使用することにより、すべてのアプリケーションとそれに対するコンフィギュレーションの場所、値、ドキュメントの総体的な把握が可能になります。小さなセットアップの域を越えると、手作業ではスケールアップできないのです。

ソース管理 vs. Config - 例えば、構成ファイルをGitに保存するとします。その場合、構成ファイルと環境別設定用のリポジトリを用意した方がよいでしょう。その他の一般的なアプローチとしては、1) ソースコードリポジトリの一部として、カスタマイズの必要な構成テンプレートを用意する、2) ソースコードリポジトリに運用環境専用のコンフィギュレーションを用意する、3) すべての構成ファイルと環境別設定をソースコードリポジトリに格納する、などがあります。Configは、そのコアに環境変数を組み込んでいます。Gitを使用する場合、構成ファイルは単なるプレーンなテキストファイルに過ぎません。環境による違いや、環境別設定をコードの実装(あるいはライブラリの利用)は、依然として手作業で行わなくてはならないのです。Configは構成ファイルの管理を可能にします。新しい共通キーをすべての環境に適用することや、環境別のタブを使って独自を変更を加えることができます。Gitと同じように、Configにもバージョン機能があり、プルによって必要なコンフィギュレーションを取得することが可能です。さらにConfigは、要求された環境用のコンフィギュレーションのみをプルして、オンデマンドで適切なコンフィギュレーションを生成します。GitHubのようなGitホストと比較した場合、Configには、構成ファイルが常にプライベートであるというメリットもあります。間違って公開してしまうことはありませんし、パブリックなクローンも簡単には作成できません。Git(あるいはGitHub)にはない機能としてはその他に、レビューや承認のワークフロー、保管中の暗号化、プッシュ配信、タイプセーフな編集機能などがります。
 
マイクロサービス vs. Config - この一例がSpring Cloud Configです。Spring Bootを使用中ならば非常に便利です。実際にはSpring専用ではありませんが、独自のクライアントを書く必要があります。Configが優れているのは、次のような状況です。デプロイ時ソリューションを希望するが、他のサーバの管理や実行時依存の導入は避けたい場合。コードを修正したり、構成ファイル用のサードパーティ製ソリューションを探したりすることを望まない場合。ユーザフレンドリなインターフェースでコンフィギュレーションを管理したい場合。
 
集中型サーバ vs. Config - ZooKeeperを使用する場合などがこれに当たるでしょう。問題の半分はコンセンサスの獲得と企業側の導入にあります。あなたの会社が集中型サーバを運用していて、アクセスが可能ならば、この方法を選ぶべきです。コンフィギュレーションにファイルを使用するアプリケーションをサポートする必要があるが、ファイルとKV間でコンフィギュレーションを変換する中間スクリプトを書きたくない、という場合には、Configの方が優れています。私たちのロードマップには、ConfigからGitあるいは集中型サーバへの構成ファイルをプッシュする機能が掲載されています。これはConfigが既存のソリューションを補完する一例です。
 
IaC vs. Config - Ansibleなどの構成管理です。この話題は、システムのプロビジョニングとコンフィギュレーションに最適かというような、システム管理者の領域になります。ローカル開発マシンと運用マシンに関わらず、同じ方法で構成ファイルを管理したいのならば、Configの方が秀でています。Configが既存ソリューションの置き換えではなく、補完するものである、という好例です。システムのプロビジョニングとコンフィギュレーションに関するマジックはすべてAnsibleが行います。アプリケーションのコンフィギュレーションの段階になったら、AnsibleがConfigから構成ファイルをプルするのです。Gitから構成ファイルをプルする場合と概念的には同じです。

クラウド移行を果たしていない企業にとって大きな問題となるのは、ConfigがSaaSサービスであるということです。これに対しては、オンプレミスプランの提供で対処します。VPCですぐに使用できるように、AWS Marketplaceなどのクラウドマーケットで提供する準備も進めています。

Configのキャッチフレーズは、“すべてのサーバと環境の構成ファイルを管理するための最も簡単な方法”、というものです。キーワードは“最も簡単(easiest)”です。既存の構成ファイルをインポートして、プッシュかプル、いずれかのデプロイメントを選択します。環境を指定し、環境変数を比較し、アプリケーションを検索します。数分あれば、セットアップして無償プランで実行することができます。

InfoQ: ソースの値が変更された時、クライアントの構成情報をどのように更新するのですか？クライアントに(キャッシュの無効化などで)検知する責任を持たせるのか、サーバから通知するのか、実現方法としてはどちらがよいのでしょう？

Config: これには２つの面があります。コンフィギュレーションのデプロイとリロードです。

まずデプロイについて。私たちはConfigを、可能な限り多くのアプリケーションで使えるようにしたいと思っていました。そのためには、デプロイ時に依存性を解決する必要があります。簡単に言えば、viやnotepadを使って手作業で構成ファイルを編集するのではなく、Configが更新するのです。では、どうやって構成ファイルを更新するのでしょう？私たちはプロセスやインフラに応じて、複数のオプションを用意しました。最も簡単なのはプッシュ展開で、Webインターフェースから起動するだけです。構成ファイルはサーバにscp転送されるので、sshアクセスが必要です。複数のサーバを一度に処理するバッチプッシュもサポートしています。もうひとつのオプションは手動プルで、Gitからのプルと同じような方法です。cronやタスクマネージャがプルする、自動プルという方法もあります。最後のオプションは手動によるエクスポートとダウンロードです。
 
リロードについて。構成ファイルを対象マシンに展開した後、アプリケーションは構成ファイルのリロードの必要性をどうやって知るのでしょう？これにもいくつかのオプションがありますが、いずれにおいてもアプリケーション側のサポートが必要です。プッシュ時にはカスタムスクリプトの実行が可能なので、アプリケーションがSIGHUPコマンドをサポートしているのならば、これを使って送信することができます。アプリケーションがファイルのタイムスタンプで変更を検知してリロードする、という方法もあります。最後のオプションとして、Configタイムスタンプ変数を構成ファイルに組み込むことが可能です。デプロイメント毎に構成ファイル内のタイムスタンプが更新されるので、アプリケーションがタイムスタンププロパティの変更を定期的にチェックするのです。ファイルのタイムスタンプ検知と似ていますが、こちらでは構成ファイルをチェックします。
 
私としてはSIGHUPのサポートをお勧めしますが、JavaアプリケーションやWindowsなど、この方法が使用できないアプリケーションやオペレーティングシステムもあります。その場合はSIGHUPの代わりに、コンフィギュレーションのリロードをオンデマンドで通知できるようなコマンドを実装しておくとよいでしょう。

InfoQ: すでに設定ファイル管理に投資している人にとって、Configはどのように機能するのでしょう？ドロップイン・リプレースなのでしょうか、既存のソリューションと同居して機能するものでしょうか？

Config: 既存の構成ファイル管理が単にGitを使って構成ファイルを保存して、すべての環境をオーバーライドするものならば、Configはそれよりも優れたソリューションになるでしょう。Git操作の大部分が自動化されている場合は、ConfigがGitにプッシュすることで、既存のプロセスをそのまま維持できます。この方法ならばすぐに着手して、段階的な移行が可能になります。
 
マイクロサービスソリューションを採用している場合は、引き続きマイクロサービスがコンフィギュレーションを取得できなければなりません。このコンフィギュレーションをファイルシステムやソース管理からではなく、Configからにすることができます。
 
集中型の構成サーバに満足しているのであれば、そのまま使用してください。もしもバージョン管理をその構成サーバと併用しているのであれば、そのバージョン管理をConfigに置き換えることができます。Configは、ファイルやKVストアに適応しないような複雑なコンフィギュレーションの必要なアプリケーションをサポートすることによって、構成サーバのさらなる補完が可能です。
 
Configは既存の構成管理ソリューションを補完するものです。 IaCスクリプトの一部(マニフェスト、プレイブックなど)は、ファイルシステムやソース管理ではなく、Configから構成ファイルをプルするようになります。

InfoQ: 機密性の高いコンフィギュレーションに外部パーティを信用するには、信頼性が必要です。十分な保護機能を持ったアズ・ア・サービスの構築には、どのような方法を用いたのでしょう？アーキテクチャについて説明して頂けますか？

Config: よく聞かれる質問です。ありがとうございます。一番よい方法は、データ保管中は機密情報を暗号化しておくことです。こうすれば、構成ファイルが内部ネットワークのサーバ、クラウドサーバ、社内のラップトップ、GitHub、あるいはConfigのどこにあろうとも、機密情報を知られる心配はありません。しかしながら、機密性の高い設定値であっても通常は暗号化されませんし、サードパーティアプリケーション用の構成ファイルなどではコントロールできない場合もありますから、すべてのケースに対するソリューションにはなり得ません。

構成ファイル内の機密情報を暗号化するという理想的シナリオを支援するために、Configでは、値を容易に暗号化および復号化するためのリソースやツールを提供しています。この方法が選択できない場合は、機密性の高い設定値を指定することによって、保存時に自動的に暗号化する機能を提供しています。これらの値は、検索機能を実行しても表示されることはありません。クラウド対応が完了していない企業には、オンプレミスのプランを用意しています。社内ネットワークあるいはVPC上で、独自のConfigインスタンスを運用してください。

機密性の高い設定の質問に対する最善の解決策は、そのような情報を構成ファイルに入れないことです。このような場合、Vaultのような機密管理ソリューションが活躍します。Configのロードマップには、機密管理サーバのサポート追加も含まれています。機密情報をValutからプルして、生成した構成ファイルに置くようになる予定です。こうすれば、既存のアプリケーションでもVaultを簡単に活用できるようになります。

インフラストラクチャに関しては、Linux上でDockerを使用しています。最小のCentOSサーバを使用して、毎日更新しています。ロードバランサとWebサーバにはNGINX Dockerを使用します。バックエンドのREST APIにはJava Dockerを、データベースにはPostgres Dockerを使っています。アプリが動作し、コンテナが通信するために必要なポートのみをオープンしています。データベースにはインターネットからはアクセスできません。オフラインバックアップは暗号化して、セキュリティ監視を行っています。セキュリティテストも定期的に実施しています。

InfoQ: 構成情報が不用意にGitHubにアップロードされたために、資格情報が漏洩したという話をよく耳にしますが、一般論として、健全な構成ファイルというのはどのようなものだと思いますか？

Config: この件については、セキュリティと信頼に関する返答の中でも触れましたが、要約して、いくつかコツのようなものを紹介しましょう。構成ファイルに機密情報を置く必要のある場合は、ファイル内では暗号化して、アプリケーションで復号化するようにしてください。JavaならばJasyptのように、ライブラリを使うと便利です。Gitリポジトリホストを使いたいのであれば、必ずプライベートリポジトリを使用してください。この面ではGitHubよりもBitbucketの方がよいでしょう。構成情報は常にプライベートなものですから、アクシデントによって構成ファイルが公開されることのないようにしてください。最善の方法は、機密情報を構成ファイルから取り出して、機密管理サーバに移動することです。