「Immutable Infrastructure」 by 伊藤直也氏 #jawsdays – JAWS DAYS 2014 参加レポート Vol.02

#イベントレポート

#AWS

佐々木大輔

2014.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

JAWS DAYS 2014 参加レポート、始まりますよ！Immutable Infrastructureトラックの一発目、伊藤直也氏のセッション「Immutable Infrastructure」のレポートです！

「Immutable Infrastructure」 by 伊藤直也氏

Track2会場でのセッションだったのですが、人気があり過ぎて入りきらず、急遽中央のビッグセッション会場を使うことに。本セッションに限らず、今回はImmutable Infrastructure関連のセッションはどれも満員御礼で立ち見が出る状態でした。それだけ注目度の高いムーブメントだということでしょう。

冒頭から「早く帰ってダークソウル2をやりたい」と言い出した伊藤氏

当日お話頂いたスライドはこちらです。

Immutable Infrastructureとは

そもそも何故Immutable Infrastructureという考え方が出てきたのか？という所からセッションはスタートしました。昨今Immutable Infrastructureに関する様々な記事やBlogエントリが出ていることからご存知の方も多いかと思いますが、「不変な、状態を持たない、廃棄可能なインフラ」をImmutable Infrastructureと呼ぶようになってきました。しかしインフラとはシステム拡張であったりセキュリティアップデートなどで日々変わるのが今まで「普通」とされてきた為、この考え方をすんなり理解するのが難しい方もいらっしゃるのでは無いでしょうか。正直なところ私も最初はそう思っていました。

サーバは様々なメンテナンスやチューニング、または障害対応などで日々状態が変わりますが、それを管理するのは用意ではありません。管理手法として手順書を整備したり、自動化したり、Chefなどの構成管理ツールを使ったりなど、様々な手段がありますが、どれも管理コストが高いですよね。伊藤氏が「障害対応で急いで対応したことが手順書や設計書に反映されなかったりする場合もある」という例を出されていましたが、まさにそういった抜け漏れを管理するのはとても大変です。

「管理が面倒なら管理しなければ良いじゃない！」がImmutable Infrastructureの考え方の基本であるとして、Chad Fowler氏が書いたBlog記事「Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components」と、Blue-Green Deployment(既存環境とは別に新環境を作り、EIPの付け替えやLBの切替などで自動的かつシステマチックに環境を切り替える、安定稼働したら既存環境は捨てる、というデプロイ手法)を例に出されていました。

そして「この考え方は他のサービスでも既に実施されている」として、HerokuとTravis CIでの例をご紹介されていました。例えばherokuはgit pushするたびに新しいコンテナを作り既存環境のアップデートなどを行わないために無停止で切替が出来るような仕組みになっているそうです。

また、こういったImmutableな取り組みによってAWSでは1時間に1000回デプロイしているとのことで、このデプロイのスピードを上げることがイコールビジネスのスピードを上げることに繋がるとのことでした。

Immutable Infrastructureを支える技術

このImmutable Infrastructureという考え方が何故今注目されるようになったのか？その経緯として、仮想化、そしてクラウドという技術の定着により環境が手軽に扱えるようになったこと、そしてInfrastructure as Codeという考え方が出てきたことがあるとのこと。ここで伊藤氏の著書である「入門Chef Soloを持っている人は挙手して下さい」と言うと、会場の7割以上が持っているという結果に！(僕も持ってます！)発売から1年が経過しましたが今でもコンスタントに購入されているそうです。

ここからはこのImmutable Infrastructureを支える技術について様々なツールや事例を交えてお話頂きました。Configuration Management ToolとしてはChef、Puppet、Ansibleなどがありますが、当初はCFEngineを使われていたとのこと。そして現在一番有名であろうChefについては「”サーバの構成を自動化するツール”ではなく、”サーバの状態をコードにする”が本質」と仰っていました。つまりコード化されたことによって、プログラマブルに扱う事ができ、アプリケーション開発のノウハウやワークフローをサーバに適用出来るということですね。ここで伊藤さんが例に出されていたのが、まずコードなんだからgitで管理してしまえばインフラをpull requestで更新管理でき、そしてコードレビューも出入るということ。そしてテストもコードですればいい、というのがserverspecであること。じゃあインフラでもCIすれば良いじゃないかと、gitでcommitしたらCIツールがgitの画面上にテスト結果を返してくれる、という例をお見せ頂きました。これはすごい。

冪等性

Immutable Infrastructureという言葉が定着すると同時にこの「冪等性」という言葉も良く聞くようになりました。冪等性とは「ある操作を何回やっても結果が同じこと」ですね。インフラがコードとして見える化されたと共に、コードで書いてるんだから結果が必ず同じ状態になっていることが保証されるべきだとのこと。一から立てたサーバでも、中途半端にセットアップされたサーバでも、同じコードを実行すれば同じ状態になること。この言葉だけ見るととても大変そうですが、大部分はChefが面倒見てくれるのでそんなに困難では無いと仰っていました。ただ「サーバの状態を考慮しなければいけない」というのはとても面倒臭いので、そもそも状態は管理せず、必要になったら新しく作る、要らなくなったら捨てる。そしてそれが可能なように、システムに「Statelessであること」という制約を与える。それがImmutable Infrastructureだとのことでした。

Immutable Infrastructureの実現に必要なこと

ではどうやってImmutable Infrastructureな環境を構成するのか？まずInfrastructure as Codeは前提であり、サーバやインフラを動的に扱うことが出来なければImmutable Infrastructureの利点が活かされないとのこと。そして新しい環境を作成するときに時間がかかっていてはデプロイスピードが落ちてしまうため、起動に時間がかかるVMよりも一瞬で起動するコンテナのほうが向いているとのことでした。そしてコンテナをプログラマブルに扱うツールとしてDockerを紹介されていました。Dockerは先日Version 0.9がリリースされたばかりですね。弊社でも話題になっていました。こうして廃棄される環境を前提にすると、新規環境でも全く同じように動くことをアプリケーションが保障しないといけない為、アプリケーションの再現可能性が要求されます。そして結果的にアプリケーションがポータブルになると仰っていました。このポータブルとはそのままの意味で「簡単に持ち運び出来る、渡せる」という意味で、例えばあるアプリケーションを誰かに渡すときにあれこれ必要な環境や設定方法を指示しなくても、gitからpushしたらどの環境でも一発で動くようなことを指されていました。これが「システムにStatelessであるという制約」による効果だという事ですね。

Immutable Infrastructureの課題

Immutable Infrastructureの課題を考える例として、Cloud Foundryのアーキテクチャ図をご紹介されていました。システムとして考えるとコンテナとDockerといったアプリケーションを動かすところだけでは足りず、監視や権限管理など様々なミドルウェアが必要であり、まだまだ環境が揃っていないとのこと。またどうしても状態を持ってしまうステートフルなコンポーネント(例えばDBやストレージ)などをどう扱うのか、という点についえては、全てをStatelessにすることがImmutable Infrastructureの目的ではなく、Statelessであるべき箇所をImmutableに扱おうということが目的であり、例えばログなどの状態についてはfluentdで外部に配置するなどの仕組みを用いるべきとのことでした。

構成管理ツールの未来

Immutable Infrastructureのように「そもそも構成を管理しない」という考え方になっても、Chefなどの構成管理ツールが不要にはならない。何故なら前述の通り、Infrastructure as Codeの本質は自動化や状態管理ではなく”サーバの状態をコードにする”ことであり、Immutableによって必要の無い機能が削られた、Immutableにフィットした構成管理ツールが出てくるだろうとのこと。別のレポートも記述しますが、宮下剛輔氏も同じことを仰っていました。

これから

最後にまとめとして、今まで固定だと考えられていたインフラ的コンポーネントが動的になってきたことで、昨今のサーバ/インフラパラダイムの集大成としてImmutable Infrastructureが生まれたのであり、これから色々な概念や実装がこの考え方に集約されていくだろう、というお言葉で締められました。