クラウドやるならアプリやインフラの垣根はなくさないと

フェイクあり。

オンプレからクラウドへのシステムリプレイス案件に携わった。PM はイベントに登壇して「エンタープライズにおけるクラウド移行の勘所」みたいなのを語ってるような人だったので、さぞ見識が深いのだろうと思っていたけど、いざ蓋を開けてみたら何にも分かってないことが判明した。

インフラの構築コストと設計コスト

確かに、クラウド化によって、サーバ構築の手間は物凄く減った。マシンスペックを選択してボタンポチーして鼻ホジーして待ってたらサーバが出来上がる。ミドルウェアや監視ツールをプリインストールしてくれるような機能もあったりするし、スケールイン・スケールアウトも容易だ。

ただ、当然ながら、インフラ構築はコレで終わりではない。

サーバインスタンスに直接 Public IP を振ると冗長化しづらいし、侵入の危険性もある。そこで、仮想ネットワークに閉じてインスタンスを配置し、インターネットからの流入口はロードバランサに集約する。その上で特定のポートだけ開放して LB とインスタンス間の通信を許容するよう、ファイアウォールを設定する。DB が絡んだり、クラウド外のシステムとの連携があるとさらにネットワーク構成が複雑になる。

ココまでは、クラウドに限らずオンプレでも同様に考慮すべき、インフラ設計の一般論。

クラウドサービスを利用する場合は、どうしてもそのクラウドベンダごとの仕様や特徴に合わせた考慮が必要になる。サービスの仕様上、この外部サービスとの連携は出来ないだとか、PaaS の場合は IaaS ほどチューニングの自由度がないだとか。

先述の PM は、この「クラウドベンダごとの特色に合わせた思考」が全く出来ない人で、旧態依然なオンプレ思考が色濃く残る一般論でしか喋れず、「何で自分が思っているように簡単に行かないんだ！」とお怒り。ウーン、でもこのクラウドベンダに決めたのアンタだから、少しは勉強してくれ。

インフラ設計はアプリに依存する

さて、システムを構築するにあたり、サーバのスペックや冗長構成はどのように決まるだろうか。

それらの要件を決めるための視点は、一般的には以下のようなモノが考えられる。

システムの利用者数は、そのシステムがどんなシステムかによって決まる。社内向けなら人数はそこまで多くないだろうし、B to C な Web システムなら百万人規模のアクセスを見越すことも当然ある。

システムが処理するデータ量や、期待する処理時間を決めるにあたっては、そのシステムの実装が大きく影響してくる。ミドルウェアより上の、ソフトウェア = アプリケーションの領域で、どのようにシステムを実装するつもりかによって決まってくる話なワケだ。特に、スクラッチではなくパッケージを利用している場合は、予め最低スペック要件が提示されているはずだ。

要するに、サーバのスペックや台数を考える時は、そのサーバに載せるアプリのことをよくよく把握しておかないと決められないというワケだ。当たり前のことだが。

「インフラチーム」と「アプリチーム」という垣根

それなのに、PM の思考はオンプレ寄りなので、「キミたちはインフラ担当」「キミたちはアプリ担当」とチームを別けてしまった。

コレだと、アプリ担当の人間は自分達が使用するパッケージと、それを活用した実装部分にしか目が行かなくなり、ハード (= インフラ) 的な視点が欠落してしまう。逆に、インフラ担当の人間も、アプリ担当が何を使い、どう実装しているのか分からない (分かりにくくなる) ので、どんなウワモノが乗るかが分からず、完全に推測でハード的なスペックを決めたりしないといけなくなる。

インフラとアプリがチームとして分断されると、ミドルウェア領域の話が宙に浮いてしまう。DB と接続するデータソースの定義だとか、JVM のヒープ設定だとか、そういうミドルウェア領域の設計・実装は、アプリ担当とインフラ担当のどちらがやるの？というところがうやむやになり、お互いに押し付けあってしまう。

アプリ担当的には「マシンスペックとか決めたのはインフラ担当なんだから、その情報をベースにミドル設定もしてよ」と思いたくなるし、インフラ担当としては「そのアプリが必要な設定はインフラ側では分かんねえよ、お前らアプリ担当の連中が握ってるんだろうからお前らがミドル設定しろ」と言いたくなるワケだ。

インフラチームが別部隊に別れる組織構造は、オンプレ時代はよくあった話だ。物理的にサーバを調達し、会社のサーバルームで物理的に構築していくワケだから、アプリ開発する人間とは地理的にも離れるし、専任性が高まるのは自然な話だ。

この場合、システムを載せるとなると、「アプリ担当チーム」にあたる人間たちが、自分たちのシステムに必要なマシンスペックを計算し、「インフラ担当」に連絡してサーバを調達してもらっていたはずだ。インフラチームも自分たちの専門知識の範囲でハード寄りのアドバイスなどはするが、主導するのは「アプリ担当」側、といってよかったはずだ。そして、インフラ構築が終わると、LB やサーバの IP アドレスがインフラ担当からアプリ担当に連絡されるので、あとはアプリ担当がミドル含め設定していく流れだ。

物理的にも距離が離れているからこそ、このようなコミュニケーションルートが自然になっていたと思う。しかしそれはオンプレ時代の物理的な制約による組織構造であり、クラウドを活用するにあたっては邪魔でしかない考え方だ。

仮想化技術により色々なリソースが抽象化されているので、オンプレの感覚だけではなくクラウドに知見を持った人間がいないと、上手く話が出来なかったりすることはある。それでも、ハードウェア選定はウワモノありきでしか決められない、もしもそうでないなら、先に決めたハードのスペック内で出来ることがアプリの要件になる、という2択には変わりないはずだ。

だったら、アプリチームとかインフラチームとかいう別け方は止めて、まずは全員でアプリ寄りな視点でのシステム要件を洗い出し、それからその要件に見合うハード面のスペックを選定すべきだと思う。

インフラに知見のないプログラマばかりが集められた

コレは先述の PM が自分のコネだけで要員を調達してるからという弊害なのだが、チームの SE やプログラマは、いずれもアプリケーションの開発工程くらいしかまともにやったことのない人達が集められていた。年齢だけは重ねてるんだけど、要件定義や概要設計を経験した人間がほぼいなかったのだ。

だから、そもそもシステムの要件ってどんな要素があるのかとか、ハードウェアの性能をどうやって決めたらいいのかとか、「そういうことを考慮する必要がある」ってことすら認識していないレベルだった。

そしてクラウドの活用経験もないのに、なぜかクラウドに関しては「簡単に構築できるもんなんだろう」「とにかくお手軽で楽なんだろう」と思い込んでいて、「オンプレからただクラウドに引越しするだけっしょー？」と軽々しくのたまっていた。

先程「アプリチームとインフラチームで組織的に別けられた」と言ったが、インフラチームに割り当てられた人間たちも、こういう連中の中から適当に決められただけだった。「クラウドって GitHub ですか？」「Terraform…？TeraTerm ではなくて…？」みたいなレベルの人間たちだったのに、いきなりインフラ設計を任されてしまったのだ。

こんな感じだったから、「サブネット」の概念も分からず、ファイアウォール設定もされてない、マシンスペックの選定もパッケージの仕様を考慮してないからほとんどデタラメという有様だった。さすがに有識者からツッコミがあってだいぶ是正されてきたものの、これら諸問題の原因は明らかだった。

つまり、クラウドを使うということは、これまでサーバルームにこもって作業していた「インフラ担当」の仕事を、全てアプリ開発者が巻き取ることに他ならないのだ。オンプレ時代なら「インフラ担当」に任せっきりで知りもしなかった分野も、彼らに頼らずクラウド化するとなると、アプリ屋がハードやネットワークの設計が出来ないといけないワケだ。

勿論、個人の趣味レベルの話ではなく、エンタープライズレベルの堅牢さ・安全性が求められるワケだから、クラウド未経験とかインフラ知らないとか、そんなメンバの都合は関係なしに、「この水準以上のセキュリティは担保してもらわないと…」と社内稟議で突っ込まれるのは当然のことだ。

リリース後のことも考えて

アプリを開発するだけのプログラマは、リリース後の運用保守作業を知らない。運用保守とは何をするのか、何に手間がかかるのか、そういった知見がない。

それはその人が書くコードを読んでいても分かる。保守改修を経験してきた人のコードはリーダブルだが、開発しては転属を繰り返していた、「作り逃げ・作り捨て」が板に付いている人のコードは、読めたもんじゃない。

そういう開発屋さんの感覚では、「リリースを迎えたら仕事は終わり」なのだが、今回の案件は、クラウドリプレイス後の運用保守も、そのチームで引き受けることになっていた。

ということは、サーバの高負荷やヘルス監視、そして検知したら迅速に復旧対応、といったタスクが増える。じゃあ監視はどうするの？というと、コレもオンプレ時代は「インフラ担当」に任せっきりで、どう監視したらいいのか、何を監視したらいいのか、といった知見がなかった。

一応、24時間・365日の運用監視が必要になるという名目のシステムなので、夜間監視は別会社に委託するワケだが、委託しようにも説明資料が何もない。素人たちが混乱を極めるプロジェクトで、仕様書や手順書なんてモノは一切作られていなかった。

高負荷対応やシステム復旧に関しては、どうやらクラウド関連のバズワードを仕入れた人間がいるみたいで、「Jenkins サーバを立てといて、オートスケールしたり、インスタンス生成やアプリのデプロイを自動化したりしましょう！DevOps ってヤツです！」って意気込んでた。運用コストも下がるだろうってことでやることになっていたのだが、「Jenkins サーバ」とか言ってる時点でお察し。巷の CI・CD ツールには目もくれず、考慮不足の自前スクリプトを時間かけて実装して、後で全然実用に足りないことがバレて大問題になった。

一連の問題に気が付かない PM

ココまでの話から容易に察してもらえるだろうが、このプロジェクトの PM は、自分の考えに固執するタイプだ。自分の考え (一般論) が正しいし、それで上手くいくと本気で思っているのだ。ハードやインフラの知識がない人ではないのだが、オンプレ時代の「インフラ担当」に任せてきた仕事をまるっと巻き取ることの難しさには全く気付いていないようだった。

「インフラ担当を任命したし、あとは上手くやっといてもらえるもんだろう」と思ったのか、PM は要件定義段階から雑にフェードアウト。渡された見積書にもロクに目も通さず OK を出し、なんとなく開発がスタートしていた。

オンプレからのリプレイス案件だと言いつつ、アプリ改修も同時に大量に行っちゃう、よくあるバカな案件だったので、アプリ担当は改修作業で手一杯だった。インフラ担当も、慣れないクラウドの壁にぶつかり、数々のトラブルが多発していた。

PM が異変に気付いたのは、結合テストが完了予定日を2ヶ月過ぎても完了していなかった時だった。アプリ担当とインフラ担当の間で情報共有、知識ベースのすりあわせがされないまま、中途半端にお互い隠蔽体質なまま進んできたので、アプリをクラウドサーバに載せた後でトラブルが多発していた。ミドルウェアの設定もそうだし、アプリの都合によって「ロードバランサでこういう制御が必要だ」みたいな話が出始めたりしていた。

さすがに PM もヤバいと思ったようで、クラウドの有識者を雇ったのだが、そもそも根本的にインフラ設計に欠陥があることが判明。しかしその時点で構築されていた構成は、PM が雑に承認した見積に沿っているモノで、欠陥を改善するためにはその見積よりも大きな金額がかかることが明白だった。

開発工程も半ばを過ぎたところで、いまさら見積の不備を指摘される PM。明らかに予算が足りず、リリースにこぎつけられるか、リリース後の運用体制が整うかも分からなくなった。

読んでいなかった (もしくはクラウドの知識がなくて読解できなかった？) 見積書とはいえ、責任は PM にある。本人もパニックみたいで、「何でこんなことになるまで誰も言ってくれなかったんだ！」などとのたまっていたが、いやもういい歳した大人が「誰かに注意してもらわないと私は見積書を見過ごしちゃいます」と告白してるのに等しい発言はさすがに吹き出しそうになった。有識者からは「でもあなたがこのおかしな構成で承認しちゃってますから、認識してるはずだと思ってましたが…」と正論を言われ、苦し紛れに「この見積作った奴連れてこいや！」と怒鳴り散らしたりしてた。片腹痛い。

実は自分はこの頃にテコ入れとして雑に投入されたメンツの一人なのだが、既に1年近く開発してるはずなのに全然成果物がなく、最初は全然状況が掴めなかった。あちこちにヒアリングして回った感じだと、みんな自身がこの案件の内容に対して実力不足なのは薄々自覚してて、恥ずかしかったり、言いにくかったりして、内々で問題を抱え込もうとする傾向にあるのが分かった。だからアプリチームの都合はインフラチームに聞こえてこないし、インフラチームもアプリチームに何か言われるまで黙ってたりしたみたい。

組織構造どおりのシステムが出来上がる、「コンウェイの法則」という言葉があるが、このシステムはまさにこの法則を体現している。いや、構築が出来ていればまだいいんだけど、今のところまともに動かないからね。下手したら UAT (ユーザ受け入れ・ユーザ承認テスト) で却下されてリリースできないかもしれない。

個人的には、そもそもこのプロジェクトに絡まされた意味 (経緯) が分かんないので、どうにでもなったらいいのに、と思っている。一般論しか知らず「クラウドは楽だ」と思い込んでた連中が、いざやってみて「全然上手く使えなかった」と挫折してゴメンナサイする姿が見てみたい。そのくらいのお灸をすえてやった方がいいと思う。

クラウドは全領域に深い知識が要る・全員が高いスキルを有していないとダメ

ココからは、このチームがこうだったら成功していただろうな、という感想。

何度か述べたとおり、クラウドというモノは、アプリケーションそのもの以外に、ハードやネットワーク、運用に至るまで、システムを構成する全ての領域に対する設計が要る。設計をするには知識が要る。すなわちフルスタックでないとならないのだ。コレは IaaS だろうと PaaS だろうと FaaS だろうと関係ない。コンテナ化しようがしまいが、システムをクラウド上で動かすためには、アプリ領域だけではダメで、インフラ領域も知らないといけないのだ。

そして、チーム内で役割分担がある程度できるのはいいのだが、「アプリ領域を知らない人」「インフラ領域を知らない人」がチーム内に1人でもいると、恐らくクラウド活用は失敗する。全員がフルスタックでいるべきだ。

リーダや PM 層になると、日本では実際に開発したり手を動かさない場合が多いが、個人的には、クラウドを活用するなら上の層の人ほどコードを読み書きして、何についても一番詳しい人間でいないといけないと思う。メンバに丸投げしていい分量ではないし、全領域を俯瞰しながらのハンドリングが重要になるので、上に立つ人間は誰よりも賢く、実態を正確に知っていないといけないのだ。細部を省略していたり、一般論で語っていてはダメだし、Terraform や CLI ツールは当たり前に使っていないといけない。

「そんなの無理ゲーじゃね？」「そんな優秀な人いないって」

うん、そうだと思う。だからそういう素人しかいない古臭い日本の企業は、オンプレからクラウドへの移行なんて難しいこと止めた方がいい。彼らにはコレをやる能力がない。