Cloud Native

Cloud Nativeというお題目で講演や発表を見かけることが多くなった。クラウドの良さを積極的に活かそう、そのノウハウを共有しようというスタンスは大変ありがたい。今後より深い議論や技術方式の確立などが望まれる分野だと思う。

個人として、Cloud Nativeを語る上で気にしなくてはいけない観点が3つあると思う。1) レジリエンシ、2) アプリケーションデベロッパーフレンドリかどうか、3) モニタリングと運用容易性のビルトインの3つ。1のレジリエンシは、耐障害性という言葉よりもクラウドにふさわしく、よりしなやかに障害に対応できる・対応しやすい、という特性のこと。Cloud上にサービスやアプリケーションを安全に生産的に作っていくためには、障害に強い状況を最初から組み込んでおくことが大事なので、プラットフォーム側で提供するか、またはサービスのコア部分に入れ込んでおくことが大事。

レジリエンをより概念としてきちんと知りたければRichard CookのResilience in Complex Adaptive Systemsあたりを見ると良いと思う。以下2つの動画はおすすめです。クラウドのプラットフォーム自体はもちろん兼ね備えている特性ですが、より効率的・効果的にサービスを提供するのであればその上で構築されるサービスも備えておくべき特性と思う。

2つ目は当然ですが、クラウドのメリットを十分に理解してアプリケーションデベロッパーだけで容易に開発できることが望ましいので、開発しやすい事が望ましい。そのためビルディングブロックをスタック上に下から積み上げるアプローチはあまり良い手とはいえないし、それはユーザが求めているものというよりは、どちらかというと提供者目線ではないかと感じる。自動化で部分的にはカバーできても、最初から組み上げないほうが望ましい。これから、こと日本に関しては開発・運用ともに人不足でまわらない状況がより深刻になり、ビジネスにも相当インパクトが出ることが予想される。なので、アプリケーション開発の少数名だけで開発できることが大事。もともとクラウドの良さは非常に限定された少数名がサービスを徹底活用することで、大人数のある程度のクオリティのところまでと同等かそれ以上を出力できることが良さなので、Cloud Nativeというならばまさにここが本筋と言っても差し支えない。

3つ目はモニタリングと運用容易性。どうしても人がいない中でになるので、できれば最初からモニタリング項目や運用のところはDay 1から既にカバーされていてほしい。これらがビルトインされて点は必須と言って良いと思う。運用のスキルがそこまで高くない開発者でもそこそこのところまでやれるようになっていてほしい。観測している範囲だと、運用をしっかりできる技術者の人は常に高負荷なことが多く、それも人数的・規模的に限界な事に見える。心身ともに疲労困憊なことも散見される(あくまで観測内)。運用容易性の先としては、オートヒーリングができると望ましい。何かしらサービスに問題があると思った時にスケールアウトやセルフリプレースで人手をかけずに自己修復してくれるのが良いし、その仕組が内包されているべきと思う。ちなみに最先端の企業だと、アプリケーションサーバごとのチューニングを人手ではなく、機械学習とプロビジョニングの仕組みを駆使してシステムが負荷状況をみて自動チューニングをする。その間に人が介在することはゼロだ。安定的に複雑なシステムを動かそうとすると、人手の介入を徹底的に減らすほうが安定する、その入り口くらいまでは来てそう。

余談としてCloud Nativeでロックインが危ない・危険だと語られるが、そういう人は言いたいだけである。利用するサービスや機能がロックインされることはどのプラットフォームでも起きていることだし、事実避けられない。避けようとすると、クラウドのもつ様々なメリットを失う。もちろん設計や実装するタイミングで適切な抽象化をすることで軽減できるがすべてのプラットフォームから自由になることはほぼ無理なので、費用対効果を見て現実的にどこまで使うか・依存関係のボーダーラインをどこにひくかが目利きとして大事だと思う。だからといって、100%クラウドが提供するサービスを使い切るのは大反対で、それはそれで極端すぎると思う。依存関係の管理については、どこかで自分の考えを書くつもり。

現状前職プラス少し触った限りではあるが、この分野で一番進んでいるのはPivotalのPivotal Cloud Foundry(PCF)だと思う。普通にCloud Foundryのプラットフォームとしても使えるが、Cloud Nativeなプラットフォームとして使うことを想定して記述する(Pivotal Web Servicesの方、多分普通のPCFでもできると思う)。アプリケーション・フレームワークのSpring Cloudやレジリエンシを高めるNetflixのオープンソースをビルトインしており、アプリケーション開発者の数名でかなりのところまでいけそうで、かつIaaSのプラットフォームは選ばない。インパクトが大きいのがSpring Cloud/Spring Bootを取り込んでいる点で、世界的に開発者が馴染みが多いので、始めやすさもある。次はAWSのBeanstalkかAPI Gateway/Lambdaの組み合わせでの構築。個人の意見として、ガチガチなPaaSというよりは、その少し下のレイヤを丁寧に提供してくれる方がサービスを作りやすい方し利用側の要求に答えやすいと思うので、そういう主義趣向も現れた結果だと思うが、事実、PCFやLambdaなどが利用され初めているのをみると、あながち間違いでもなかったようだ。

考え方の根本としては、Cloud Nativeというのであれば、クラウドのダイナミックな特性を理解して使いこなそうとするマインドで接してほしいし、それもないのに言葉先行なのであれば、何の意味もない、と思う。

Show your support

Clapping shows how much you appreciated Shinpei Ohtani’s story.