「こんなのクラウドネイティブじゃない」と思うこと：草間一人×青山真也 クラウドネイティブ対談（4）（2/2 ページ）

[三木泉，＠IT]

印刷

通知 連載「％」の新着をメールで通知

隕九ｋPost

Shareシェア

はてなブックマーク

SharePocket Button

「何をやるにも数日かかる」

青山　次は、「何をやるのにも数日かかる」系の話です。アップデートするにも、スケールするにも数日かかるといったように、何かをやろうとすると必ず時間がかかってしまうのは、クラウドネイティブ的にはよくないと思います。

何をやるにも数日かかる　#こんなのクラウドネイティブぢゃない

――それは「どういう原因であっても」ということですよね。

青山真也氏 「Kubernetes好き」を公言し、Certified Kubernetes Application Developer、Certified Kubernetes Administratorの認定資格を持つインフラエンジニア。サイバーエージェントに所属しながら、他の事業会社に対する技術アドバイザーや客員研究員も務めている。Cloud Native Meetup Tokyo/Kubernetes Meetup Tokyoのオーガナイザーでもある。著書に「Kubernetes完全ガイド」「みんなのDocker/Kubernetes」

青山　自動化を導入しきれていないということもあるでしょうし、承認の仕組みが変えられていないということもあると思います。スケールする前提でアプリケーションがつくられていないということもあります。要因はいろいろありますが、「何かしたいと思ったときに、『ハイ・ベロシティ（high velocity：高速）』で実行する」ということを達成できているかというのはとても大きいと思います。

草間　あと、実践が進み始めた組織でありがちなこととして、「APIドキュメントが追い付いていない」というものがあります。社内の他のチームがつくったサービスをたたきにいこうとしても、API定義が更新されていないとか、そもそもAPIドキュメントがないなどで使えない。同じ会社なのに、相手先のリポジトリのソースコードを読んで初めて分かるということが起こりがちです。

APIドキュメントが追い付いていない　#こんなのクラウドネイティブぢゃない

草間　先ほどは長いドキュメントの話がありましたが、ドキュメントが一切ない文化も、組織としてスケールする体制を考えた時には厳しいのかなと思います。

――関連して、「インナー・ソーシング（Inner Sourcing）」という言葉がありますが、同じ組織の中であっても、同じオープンソースソフトウェア（OSS）プロジェクトのメンバーであるかのように、部署を越えた協力をする文化があったほうがいいといいうことでしょうか？

草間　ないと厳しいと思いますね。他のチームのリポジトリにPull Requestを投げるとか、Issueを立てられるとか、コミュニケーションができないと難しいです。そこはOSSと一緒だと思います。

――青山さんは「クラウドネイティブじゃない」がまだありますか？

青山　私はあと2つあります。「仮想マシンの代わりにコンテナを使いました。はいクラウドネイティブ」というのが1つ。もう1つはニッチな話ですが「このコンテナ、IPアドレスは何ですか？」「IPアドレス変わっちゃったんですけど」などと聞いてくるケースです。アプリケーションコンテナの利用作法を理解しきれていないパターンが時々見られますね。

仮想マシンの代わりにコンテナを使いました。はいクラウドネイティブ　#こんなのクラウドネイティブぢゃない

このコンテナ、IPアドレス何ですか？　#こんなのクラウドネイティブぢゃない

「KubernetesのYAMLを会議参加者全員で目視確認」

草間　僕はもう1つあります。仕事上、一般企業とお付き合いしていると、「○○品質」「○○クオリティ」「○○グレード」ということを、○○に企業名や産業の名前を入れて主張されるところがとても多いです。ただ、「○○品質」を気にしすぎるのは、クラウドネイティブという観点からいうと残念なことが多いです。

うちは、「○○品質」の担保が至上命令です　#こんなのクラウドネイティブぢゃない

　「○○品質」を担保するために、「ここは手動にしよう」「ここは会議を挟もう」となりがちです。従来の、人間がとことん関与するという考え方がベースとなってしまっていて、クラウドネイティブの、できるだけコンピューターに任せて自動化していこうという考え方とは相反する部分が大きいです。

――「○○品質」を言う人たちが求めるものは何なのでしょう？　先ほどの「SLA 100％」ですか？

草間一人氏　Pivotalジャパンに所属するソリューションアーキテクトとして、主に一般企業における開発体制や開発基盤構築の支援を行っている。Cloud FoundryやKubernetesをはじめとしたクラウドネイティブ技術に関する執筆や講演多数。PaaS全般についての造詣も深く、さまざまなPaaSとその関連技術を扱う勉強会である「PaaS勉強会」を主宰している。

草間　ぶっちゃけて言うと、責任回避じゃないでしょうか。何か事があると自分たちの責任になってしまうので、出来る限りリスクを下げておきたいという考えが働いているのではないかなと思います。誰か1人の開発者が自動化をして問題が発生したときに、その開発者の責任になってしまう。そこで組織の文化として、「あなただけが悪者にならないように、皆で責任を分担しよう、だから会議体を通そう」ということになりがちです。

　「心理的安全性」という言葉が最近使われますが、安心感を高めるために皆で責任を負おうとします。でも、皆で責任を負うということは、誰も責任を負わないということなんですよね。ですから、会議でKubernetesのYAMLをスクリーンに映し出し、これを皆で目視確認して「よし！」と言って初めてリリースが許される、というようなことが行われるわけです。

KubernetesのYAMLを会議参加者全員で目視確認　#こんなのクラウドネイティブぢゃない

　同じような例に、「既存の通報システムを使って、問題を逐一通知しろ」というのもあります。これで責任を分散しようとします。通報を受け取った人が担当者に電話をかけるだけであれば、最初から担当者にメッセージや電話が行くような自動化をしておくほうがよほど早い。

　障害対策をいうなら、仕組み的に考える必要があります。デプロイを容易にして切り戻しを迅速に行うとか、カナリアリリースで当初の影響範囲を限定するなど、クラウドネイティブの世界では回復性を高めるための技術的な解決策がさまざまに提案されています。「人がやろう」という発想ではなく、仕組みとして考えることが大切です。

　もちろん、回復性を担保するだけでは不十分で、アプリケーションのSLA自体を高めなければならない場合もあります。クラウドネイティブであっても、例えば99.999％といったSLAを目指すことは可能ですが、大きなコストがかかります。つまり、やみくもに高いSLAを達成しようとするのではなく、アプリケーションの重要性に応じたSLAを考えるべきだと思います。

――さて、最後にまとめとして、一番難しい質問です。「『クラウドネイティブ』を目指して、何をやったらいいですか」と聞かれたときに、できるだけ短く答えるとすると、どういうことになりますか？

青山　一言でいうと、（アプリケーションに関して、人が）できるだけ何もしなくて済むような状態を作り出すことでしょうね。

草間　そうですね。1日の中で、システムを直接触らなければならない時間が少しでもあるなら、多分改善の余地があると思います。

青山　全て「よしな」に動いてくれるというのが最高の状態です。「落ちたら上げる」「バグが紛れていたら戻す」といったことができるだけ自動化されるということですよね。あとは最近、カナリアリリースをした後、レイテンシーやエラーレートなどのメトリクスに基づいて、必要であれば自動的に戻してくれるツールもあります。UI（ユーザーインタフェース）のチェックとリリースを自動化するツールも出てきていますし。このように、リリース判断すらも、自動化できるようになるのがベストかなと思います。

草間　「人間が1日に下せる決断の数は限られている」という話を読んだことがあります。仕事上の判断から、今日着ていく服選びまで、全ての決断を含めた話です。1日にできる決断の数が限られているなら、決断をしなければならない場面を可能な限り減らしたほうがいい。アプリケーションの運用に関する決断を減らしていくことがクラウドネイティブへの道だと思います。そして減らした判断を、ビジネスやサービスの向上など、より価値の高い対象に向けていくのがいいと思います。

特集：クラウドネイティブとは何か？　クラウドネイティブは「攻めのIT」の前提　ではその具体的な姿とは

今や、あらゆるWebテクノロジー企業が「クラウドネイティブ」を目指している。一般企業においても、デジタル化への取り組みに伴い、この言葉が最重要キーワードとして浮上している。クラウドネイティブは、これからの攻めのITにおける前提になったといって過言ではない。そこで次に語られるべきは、「具体的に何をやっていくのがいいか」ということだ。パブリッククラウドを使えば自動的にクラウドネイティブになるわけではない。本特集では、クラウドネイティブに一家言を持つ青山真也氏と草間一人氏の対談や、事例を通じ、クラウドネイティブの具体的な姿を明らかにしていく。