Infrastructure as Code の弊害

(Image from: http://devops.com/2014/05/05/meet-infrastructure-code/)

Infrastructure as Code の弊害

本記事では、あまり触れられることのない Infrastructure as Code のデメリットについて書きます。 Infrastructure as Code ってなに?どのようなメリットがあるの? という話については、色々語られている記事がありますのでそちらをご覧頂ければと思います。

構成管理ツール色々

Infrastructure as Code というのは、 “インフラ構成をコードで管理しよう” という概念でしかないので、それを実現するためのツールが必要になります。
僕が最初に業務で使ったツールは Puppet ですが(2012年5月頃)、他にも色々な構成管理ツールがあります。

  • サーバ内部のアプリケーションやミドルウェアなど
    • Puppet
    • Chef
    • Itamae
    • Ansible
  • 仮想マシンイメージ (e.g. AMI)
    • Packer
  • インフラ全体
    • Terraform
    • AWS CloudFormation
  • DNS
    • Roadworker

参考までに現職では、 Itamae, Packer, Terraform, Roadworker を利用しており、テストツールとして Serverspec も使用しています。

ツールを使わない方が 10倍 早いという現実

たとえば、 Itamae を使って各サーバ群にミドルウェアをインストールすることを考えてみましょう。

A. 構成管理ツールを使わない場合

  1. Fabric や Rundeck などで、下記手順を対象サーバ群に一斉適用
    • Nginx を Yum でインストール
    • Nginx の設定ファイルを配布
  2. Serverspec でテスト
  3. 適用後のサーバを元にマシンイメージを作成

所要時間: 約5分

B. 構成管理ツール(Itamae)を使う場合

  1. Nginx 用のレシピを書く (Ruby)
  2. 対象サーバ用の Nginx テンプレートファイルを書く
  3. 対象サーバ用の Role ファイルで Nginx レシピを include する
  4. 対象サーバ用の Attribute ファイルに Nginx 用のパラメータを追加する
  5. Dry-run モードなどで、レシピの設定が正しく反映されるで”あろう”ことを確認する (または手元の仮想環境に適用してみる)
  6. 諸々の追加・修正したファイルを Git にコミットして GitHub に push する
  7. GitHub 上でレビュワーに Pull Request を作って、レビューを依頼する
  8. レビューが完了するまで待つ
  9. Itamae レシピを実際に本番環境に適用する (稀にエラーになるので、バグを修正して 5. に戻る)
  10. Serverspec でテスト

所要時間: 約30分

↑は 6倍 の差ですが、本番適用時にエラーになった場合はトラブルシュート&レビューやり直しなどでもっとかかります。特に Terraform は本番適用時のエラーが多いです。

複数の新規プロジェクトの立ち上げ段階などは、丸一日構成管理ツールのコードを書いている日も少なくありません。

現実とコードの乖離が深刻

また、インフラに対するすべての変更を 構成管理ツール + CI ツール 経由でやれれば良いのですが、現実はそうそう都合が良い訳でもなく、障害時や急ぎの場合には前述の問題により手動でインフラに変更を加える必要があったりします。

作業後に、構成管理ツールのコードの修正をやってもらえれば良いのですが、”喉元過ぎれば熱さを忘れる”と言うように後回しになってしまうことも多々あります。あるいは、変更作業を行った人が構成管理ツールの扱いにまだ慣れていないというケースもあります。

現実のインフラとコードが乖離した状態が長く続くと、次のタイミングで構成管理ツールを使ったときに手動で行った修正を打ち消してしまうなど、由々しき自体が発生し得ます。特に CI ツールなどと連携して設定変更を自動化しているとそのリスクはより高まります。

Infrastructure as Code の越えた先にある未来のインフラ

これらの課題を抱えつつも、 Infrastructure as Code の透明性は魅力的ではあります。しかしながら、コードと言えども結局は設定ファイルでしかなく、クリエイティブな作業ではないので楽しいものでは有りません。

これからのインフラ管理はどのようにあるべきなのでしょうか?

一つ考えられるのは、 マネージドなインフラ です。

Heroku や GAE 等の PaaS や、 AWS API Gateway + Lambda、 Found (Hosted Elasticsearch) など様々なソリューションがあります。

ただし、これらのサービスに依存し過ぎることには、ベンダロックインや使いたいアプリケーションが対応していないなどの課題もあります。

もう一つは、 コンテナベースのインフラ です。

開発者がビルドファイルさえ書けば、サーバープールに対してビルドされたコンテナを放り込むだけでデプロイし、モニタリング出来るインフラ。 Docker などの標準化された仮想化技術を使えば先のロックインや汎用性の課題も解決することが出来ます。まだまだ発展途上ではありますが、 Amazon ECS や Google Container Engine などのサービスが段々と充実して来ています。

まとめ

僕は、インフラ運用というものは基本的には価値を生み出さない仕事であると考えています。同時に、インフラエンジニアの使命はどんどん運用の仕事を減らしていき、開発にかけるリソースを増やしていくことだと考えておりますので、今後も様々な模索と努力をしていくつもりです。

DevOps Engineer, 山中


反論も含め、ご意見・ご感想は大歓迎です。
ブログ執筆を続ける活力となりますので、よろしければ下記のフォームか Twitter などでコメントを下さい。 (^^

Related

Comments

  • RaBiroroPaips RaBiroroPaips 3月 18, at 18:32

    http://www.joysum.com/askqiu/member.asp?action=view&memName=ixozafoqo

    Reply

Post Reply