インフラ自動化の歴史とDockerコンテナ
まずはスリーシェイクについて簡単に紹介しよう。同社の強みはSRE技術で、顧客のシステム状況や段階に応じたSREの技術支援を行っている。さらに最近ではクラウドで脆弱性診断と改善方法を提供するサービス「Securify」を開発し、ベータ版を無償提供中だ。
今回はクラウドネイティブの全体像とDaprを中心に解説する。nwiizo氏は「クラウドネイティブもソフトウェア開発も本質は徹底的な実践ですので、気軽に聞き流してもらえれば」と言う。コンテナについてはnwiizo氏おすすめの『コンテナ物語』（日経BP社）を読んでおくといいだろう。
インフラ自動化の歴史を振り返ろう。かつて「Infrastructure as Document」時代は、システム運用担当者が秘伝のドキュメントにそって1台ずつ丁寧に設定しながら、アプリケーションを配置していた。秘伝なので出自不明で、更新されず、いつか腐る。分かる人が徐々に退職してなんとか動かすという綱渡りな状態だ。
次に「Infrastructure as Code（IaC）」時代になると手順や前提をコードで表現できて、ドキュメントの更新が不要となり、コードを見れば全て分かるようになった。「約束された勝利の自動化」とも言われ、インフラが次々と生まれていった。nwiizo氏は「黎明期はシステム管理の自動化が、後にソフトウェア開発プラクティスの応用が焦点になりました」と指摘する。
ところが、せっかくの自動化も腐る。最初はうまくいくが、OSやミドルウェアのバージョンアップ、属人化やシステムの複雑化などで徐々に腐っていく。「触るのが怖くなったら秘伝のタレが腐敗している合図」とnwiizo氏。
そうしたなか「Immutable Infrastructure」と呼ばれるプラクティスが生まれてきた。一度構築した本番環境は更新やパッチを加えず稼働させるという考え方で、常にクリーンインストールから開始し、必要なものは全て固めてアプリを共存させない。
つまり「アプリに必要なもの全てを特定のフォーマットで固めて展開するだけで起動する」。お気づきだろうか。これが（いま馴染みのある）コンテナとなった。2013年にDockerは「コンテナ」と呼ばれるソフトウェアパッケージを実行するものをリリースした。コンテナではベースイメージをダウンロードし、必要なソフトウェアはコンテナ内にインストールし、必要な設定はコンテナ作成時に仕込んでおく。これで運用が統一的になり、テスト環境・開発環境・本番環境も同じものとして扱えて、環境の違いによる影響を受けなくなった。
なおコンテナはDocker以前にも存在しており、他のプロセスとのリソースを隔離するなど特別なプロセスを指す。いま私たちがコンテナと呼ぶものは2013年のDocker以降を指すことが一般的だ。
クラウドで要求すれば下位のリソースが自動的に割り当てられるので、組み上げ方式から呼び出し方式への変化が起きた。コンテナで取り扱いが共通化され、アプリとインフラの依存関係を断ち切ることができるようになった。なおnwiizo氏は「アプリケーションファーストがクラウドネイティブではない」と念を押す。
