「Immutable Infrastructure パネルディスカッション〜オレにも一言言わせろ」 #jawsdays – JAWS DAYS 2014 参加レポート Vol.08

JAWS DAYS 2014 参加レポート、8本目です(これにて僕の担当分は終わり)

Immutable Infrastructureトラックの最終セッション、「Immutable Infrastructure パネルディスカッション〜オレにも一言言わせろ」のレポートです！

「Immutable Infrastructure パネルディスカッション〜オレにも一言言わせろ」

• モデレータ 田中 慎司氏 [株式会社はてな]
• パネリスト 伊藤 直也氏、成田 一生氏、澤登 亨彦氏 、吉羽 龍太郎氏、宮下 剛輔氏、栗林 健太郎氏

本セッションについてはモデレータである田中氏が既にご自身のBlogに記事を書かれています(JAWS DAYS 2014 Immutable Infrastructure パネルディスカッション - stanaka's blog)ので併せてご参照下さい。

本セッションはディスカッション形式であるため、私が聞いた内容を私なりに理解してまとめたものになりますので、全ての文責は私個人にあります。もしパネリストの方や、私と同じようにセッションに参加されていた方で「ここは違うよ」という記載があればご指摘下さい。

本セッションは、事前に田中氏がまとめられていたアジェンダを元に進行されました。

Immutable Infrastructureって(文字長が)長くない?

こちらは自己紹介で栗林氏が「私はII(アイアイ)って言っちゃいますけど」と発言されたのでそれで固まりました:)

実装がPaaSに近づいていくけど、IaaSとPaaSの使い分けは?

吉羽氏：車輪の再発明を続けるとビジネススピードが落ち込む、モデルとコントローラだけ書けば動くみたいなモデルになっていくのではないか。 成田氏：時代が波打つように、IaaSのニーズをPaaSが取り込む、その逆もあって、結果としてどちらもよくなっていくようになると思う。 澤登氏：noDevsのように運用担当が減っていって、PaaSに寄っていく。pushしたら終わりみたいな世の中になるといい。 伊藤氏：現実的にはPaaSにはならないんじゃないか。エンタープライズの要件はクラウドやPaaSには合わない。そしてそっちの仕事のほうがIT業界としては多くて、Web系は全体の1割程度。業界としてはSIの人のほうが断然多い。CloudFoundryのようにアプリケーション以外の監視や権限管理のような仕組みはWeb系の人よりSIの人のほうが注目している。 宮下氏：PaaSとImmutable Infrastructureを考えたとき、今後はインフラの操作もPaaSみたいになるんじゃないか、インフラをpushする感じ。 栗林氏：個人に近いお客様に対して簡便な運用を提供する、その中で新しい技術を提供できると良い。 田中氏：みんな少しずつ違う、僕は成田さんの意見に近い。

Immutable Infrastructureの実現にあたっての課題は?

栗林氏：技術的な負債を解消するためには見える化が必要。それがInfrastructure as Codeといった形で出てきた。 宮下氏：Dockerとかいろいろ出てきているけど、まだまだ足りていない、熟れていないという印象がある。 伊藤氏：監視とか権限管理とか、Dockerに足りていないところがいっぱいある。組織的な話で言うと、Immutable Infrastructureをゴリゴリやるような中間業務をやる人を確保できるような会社はなかなか無い、というのは課題だと思う。 澤登氏：開発者/DeveloperとInfraの協力が必要、IIはInfraだけで出来るわけじゃない。Developerと一緒にやったほうがいい。 成田氏：現状のシステムをコンテナデプロイに変えるまでの道筋が長い。実際はコードの中にサーバ名が書いてあるような依存するコードがまだ残ってる。こういうのを一つ一つ切り離して整備するのが大変。一回大きくなってしまったシステムをコンテナ化するのは大変だし、それをするだけのメリットがクックパッドでは無い。それよりはゴールデンイメージで運用したほうが楽、最初の一歩としてはこっちがいい。またストレージとログについては答えが出てない、fluentは集約するだけなので集まったものをどうするかの正解がないと思っている。 吉羽氏：アプリがちゃんと作られているか、テストがちゃんと出来ているか。そういうベーシックなところがまず出来ていないんじゃないか。ステップバイステップでちゃんと段階を踏んで導入していくべきなんだけど、それやるとImmutable Infrastructureにたどり着ける気がしない。 伊藤氏：そういえばエンタープライズ案件でDevOpsしたいって言われていったらアジャイルしたいだった、ということがあった。Immutable Infrastructureやりたいって言われたらどうしよう(会場爆笑) 吉羽氏：銀の弾丸じゃないってのがちゃんと伝わって欲しい。現場でちゃんとステップを踏んでトライした結果がImmutable Infrastructureになる。 田中氏：Immutable Infrastructureってどのくらいの人が聞く話なんだろう？バズワードっぽくなっちゃってるよね 伊藤氏：バズワードって言う程広まっていない、例えばここに居るパネリストがみんな事故にあったりしたらImmutable Infrastructure自体が無くなっちゃう(会場爆笑)

Immutable Infrastructureはどういうターゲットに伝えるものなのか

伊藤氏：一番利益を受けるのは普通のWebアプリケーション作ってる人、Heroku使ってるような人。又はオンプレからクラウドに移行して、次に何をやるかを考えている人。この2方向から広まっていってImmutable Infrastructureに集約していく、ような流れになるのではないか。 宮下氏：インフラを今やってる人がやるといいんじゃないか。Immutable Infrastructureになるとアップグレードじゃなくて毎回クリーンインストールだからリスクが低い。インフラは継続的に変えていくのが難しい、そうすると技術的負債になる。これがコンテナになって一部だけ変更が楽になるとインフラの人の苦労が減るんじゃないか。 栗林氏：Immutable Infrastructureにしようと思ったときに出来ない、システムに依存性があること自体がリスクを抱えているので、Immutable Infrastructureの概念を学ぶのは誰にでも有用。 澤登氏：現場の人がサーバを捨てるという楽さを享受できる。以前EC2のインスタンスを立てるのに稟議書が必要だったことがあるけど(会場爆笑)、それはImmutable Infrastructureのように簡単には捨てられないよね。現場の人が知って、中間の人に理解してもらう、ってのがいいんじゃないか。 成田氏：経営的なメリットがないと企業では採用できない。ディスポーザブルになることで開発スピードが上がる、それが利益。その利益を経営層にちゃんと伝えることが出来ればいいんじゃないか。 伊藤氏：それをやると今度は僕のところにスクラムやりたいとかいわれるんだけど(会場爆笑) 吉羽氏：スクリプト系の言語を使ってる人はいいんじゃないか。Javaみたいなライフサイクルが長く枯れているものは捨てることを考えなくてもいい。がんがんバージョン上がっちゃうようなスクリプト系のほうが向いてる。 成田氏：逆にライフサイクルが長いものほどディスポーザブルのほうがいいんじゃないか。rubyなんかはガンガンバージョンあがるから基本皆ディスポーザブルに考えている。railsもそう。ライフサイクルが長いと1年以上そのまま維持されてしまうようなサーバになってしまい、同じサーバが作れなくなる事もあるのではないか。 澤登氏：Javaでも継続的CIをやってれば捨てなくてもいいんじゃないか。 成田氏：例えばChaos Monkeyのように、システム障害をわざと引き起こすことでシステムの強度をテストするような仕組みがあるので、ライフサイクルが長いシステムはこういったツールを導入して強度を上げる、という方法もあると思う。

Statefulなコンポーネント、例えばDBに対するIIとは

吉羽氏：そもそもWeb+DBという構成自体から考え直したほうがいいんじゃないか。AWSの場合だと購買履歴というデータがあるが、一年以上前の購買履歴はDBじゃなくてS3に保持してる。DBに頼らない構成が必要なのでは無いか。 成田氏：(クックパッドは)RDBどっぷりなのでRDBをIIにするのは無理、RDBとIIは相性が悪い。RDBをKVSに切り替えるにも再設計が必要、なのでアイデアがない。10年後くらいにストレージがすすごく向上してHW的に解消されるのを期待したい(会場爆笑) 澤登氏：Redisみたいにネットワークレイヤーで頑張るアプローチもあるのでは。でもRDBは止めた方が良い。 伊藤氏：アプリケーションはどんどんコンテナを立てられるけど、DBは一つしかないと辛い。MySQLのクラスタを作っておいて、コンテナを新規に作ったらもう一つ別のMySQLクラスタ立てるとか、DBにブランチ作れるとか、しかもマージ出来るとすごく良い。Immutable Infrastructureに併せてDBが動いてくれるといい。 宮下氏：Immutable Infrastructureの概念が広まって、それにDBが対応してくれる、というのが理想。 栗林氏：ホスティング事業だと顧客データがあり、それはIIが出来ない。出来たら会社的にメリットがあるので、いろんな解決策がこれから安く運用が出来る形で出てくるといいなと思う。

最後に一言

吉羽氏：当たり前のことを当たり前にやるのが一番流行る。当たり前のことをまずやってほしい。 成田氏：経営者の方が「Immutable Infrastructureはこれからくるぜ！」と騙されて部下の方に言って下さい(会場爆笑) 澤登氏：Infrastructure as Codeをちゃんと伝えること、まずはserverspecから。Chefはその後に導入されるべきもの。 伊藤氏：私自身がChefとSserverspecとかやってるし、そこまでは先行事例がある。そういう事例をもっと増やして世の中に広めていきたい。 宮下氏：servercpecでちゃんとテストしてからデプロイ、というのが広まればImmutable Infrastructureが広まっていくのでは。 栗林氏：ライフサイクルが長いというJavaをImmutableにする、その先行事例が伊勢神宮の式年遷宮アーキテクチャです(会場爆笑)