シェア
はてブ
2024年6月28日、29日にファインディ株式会社が主催するイベント「開発生産性Conference 2024」が開催されました。本記事では、PagerDuty株式会社にてProduct Evangelistを務める草間 一人さんによるセッション「クラウドネイティブの本質から考える、生産性と信頼性の両立」の内容をお届けします。
■プロフィール
草間 一人（くさま かずと）
PagerDuty株式会社 Product Evangelist
PagerDutyのEvangelistとして、PagerDutyプロダクトの普及と推進に携わるほか、自動化・インシデントコマンダー・Platform Engineeringの啓蒙も行っている。
人間の関与を減らしていく、クラウドネイティブの本質
草間：本日は、「クラウドネイティブの本質から考える、生産性と信頼性の両立」というタイトルでお話しさせていただきます。私は草間と申しまして、よくjacopenと呼ばれています。PagerDutyでProduct Evangelistという仕事をしています。また、いろいろなコミュニティ活動をしており、Platform Engineering MeetupやCloudNative Daysといったイベントの主催をしています。
草間：続いて、PagerDutyがどういうものなのかを簡単に説明しますと、インシデントを少ないリソースで管理し、より早く解決していくためのプラットフォームです。
例えば、システムをモニタリングするためにNew Relicなどのような監視ツールがありますが、そこから上がってくるアラートをPagerDutyで受け取ります。そして、PagerDutyで大事なアラートだけを抽出して、担当者に連絡。さらに、1人目の担当者が出なければ、2人目の担当者に連絡をするといった賢い呼び出し方ができるのが、よく使われる機能です。
草間：それと生産性に何の関係があるのかというと、今のお話が開発生産性に直接関係するわけではありません。開発生産性に関して、今日どういったお話をしていきたいかというと、一旦僕の本業から離れて、先ほどコミュニティ活動として触れたクラウドネイティブやプラットフォームエンジニアリングの切り口からお話しできればと思っています。
クラウドネイティブという言葉は、おそらく皆さん聞いたことがあるでしょう。例えば、CI/CDやコンテナ、Kubernetesなど、このあたりの技術がクラウドネイティブと呼ばれます。クラウドネイティブに関するイベントの代表をしていると、さまざまな質問を受けることがあります。
例えば、「うちはAWSオンリーなんですが、Kubernetesを使ったほうがいいですか？」とか、「コンテナのほうがいいでしょうか。VMだとダメですか？」とか、「オンプレをやめてクラウドへの移行が終わっているので、これってクラウドネイティブですよね？」とか。そういった際には、「クラウドネイティブのことを、どう捉えていらっしゃいますか」と返しています。
クラウドネイティブの定義として、CNCFという団体が出している内容があります。この定義を読むとクラウドネイティブがわかるかというと、正直わからないんですよね。僕もこれを読んでもピンときません。
この定義は、クラウドネイティブをちゃんと実践できている人が改めて読むと、「そういうことか」と納得できる内容にはなっているのですが、クラウドネイティブを知りたい人がこれを読んでも、何のことか意味がわからない説明になっているんですね。
草間：ただ、「クラウドを使っていますか」と聞かれたら、皆さん9割くらい手が上がると思います。それくらいクラウドは定着してきました。クラウドとは何かというと、NISTという米国の標準化団体が出している定義があり、オンデマンド・セルフサービス、幅広いネットワークアクセス、リソースの共用、スピーディな拡張性、サービスが計測可能であることが挙げられています。
これも少しピンとこないので、クラウドの便利なところを挙げると、使った分だけ課金されること、初期費用が安いこと、運用を肩代わりしてくれること、リソースの調達が早いこと、スケールしやすいことがあります。このあたりをメリットとして、皆さんクラウドを活用されているのではないでしょうか。
草間：そうしたなかでクラウドの一番すごいところは何かというと、人それぞれだとは思いますが、僕はAPIでコントロールできるところにあると思っています。APIがあると、プログラムから叩けるようになります。それができるということは、つまり自動化ができるんですよね。
自動化ができるということは、例えばTerraformやCloudFormationのようなIaCツールで構築することもできますし、CI/CDツールからテストが終わったら自動的にデリバリーすることもできます。他にも、オートスケールさせたりなど、いろいろと賢いことができるようになり、皆さんも既に実践されている方が多いのではないかと思います。
これはクラウドだからできることで、クラウドにはAPIがあるからこそ実現するわけです。いろんなサービスとの連携もしやすく、開発生産性という観点においては、APIでアクセスできるところが一番大きなメリットだと言えます。
皆さんのなかにオンプレ時代からやっている方がどれくらいいるかわかりませんが、クラウド化したことによって高速化して、数分で環境がつくれたり数msで処理が終わったりと、さまざまなメリットがあったと思います。
これはざっくりと表したものですが、いろんなことが自動化できてハッピーな世界に見えるなかで、問題点があるとしたら何でしょうか。そう、この人間たちは何だろうということですね。
草間：「全てのプログラマーが知っておくべき数字」というものがあります。例えば、CPUのL1キャッシュにアクセスするのにかかる時間は0.5ns、L2キャッシュにアクセスするには7ns、SSDから4KBのデータをランダムに読み出すには150ms、カリフォルニアからオランダにパケットを送って、それが戻ってくるまでにかかる時間は150msです。
つまり、nsとか、遅くてもmsといった時間のオーダーで動くのが、コンピュータの世界なんですね。ですが、例えばサーバーをつくる仕事があったとき、上司の許可を取ってからつくるとなると、そこには文字通りケタ違いな時間がかかります。人間の時間というのは、コンピュータの時間のオーダーと全然違うわけなんですね。
なので、先ほどの画で何が問題だったかというと、人間がボトルネックなんです。承認待ちに3日かかるとか、他チームの返事を待つとか、稟議で何週間かかるとか、そういったものが人間のタイムスケールなんですね。
草間：しかも、人間は遅いだけでなくミスをします。設定ミスをしたり、コミュニケーションミスがあったり、見落としがあったり、機密情報を間違ってコミットしてしまったり……。なので、クラウドネイティブの世界においては、人間が挟まらないほうが仕事が早くまわるということです。
人間を挟まない仕組みをつくっていくには、APIを持つインフラストラクチャーが非常に大事になってきます。それだけで回る仕組みをつくれるからですね。そうすると、コンピュータの時間であるnsやmsのオーダーで物事を回すことができるようになるわけです。
こうした前提条件をもとに、先ほどのクラウドネイティブの定義に戻って読んでみると、いろいろ見えてくることがあります。定義には、「クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッククラウドなどの近代的でダイナミックな環境において……」と書かれています。
この「近代的でダイナミックな環境」を先ほどの話に置き換えると、要はAPIで叩けるインフラのことを近代的でダイナミックな環境だと説明しているんですね。
それに続いて、「スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします」とあります。これはつまりAPIを活用して、人間の関与を減らしつつ、大量のリソースをさばいて自動化できる仕組みのことを表現しています。そして、そのためにはコンテナやサービスメッシュなど、いろいろなアプローチがありますよと説明されています。
草間：なので、クラウドネイティブの本質というのは、そのクラウドのいいところを全力で使った仕組み。つまり、インフラの運用やアプリの開発など全てにおいて、コンピュータの力でコンピュータを動かしていくことと、人間の関与をなくしていってコンピュータの時間軸で物事が回るようにしていくこと。これがクラウドネイティブの本質なのではないかと思っています。
僕はこれを「クラウドネイティブ思考」と呼んでいて、この考え方自体はITだけでなく、さまざまなところで使えると思っています。
認知負荷の増大とプラットフォームエンジニアリング
草間：ここまでの話をもとに、先ほどお話しした「Kubernetesを使ったほうがいいですか？」とか、「VMだとダメですか？」という質問に立ち戻ると、「本質はそこではないので、どちらでもいいです」というのが答えになります。意識すべき点は、人を挟まない仕組みになっているかどうか。それが全てなんです。
コンテナやKubernetesを使っていればクラウドネイティブなのかというと、そんなことはないんですね。例えば、手元でJavaのコマンドを叩いて、Dockerビルドを手動でやって、さらにkubectl applyも手動でやって……としていたら、それは人間の時間軸で動いているので全然クラウドネイティブではありません。
逆にVMやEC2を使っても、そのあたりを自動化してクラウドネイティブ的なことはできるわけです。僕は前職でHashiCorpというところにいたのですが、HashiCorpのプロダクトなどを使って自動化していけば、コンピュータの速度で回していけるようになります。
草間：ここまでクラウドネイティブの本質についてお話ししてきましたが、実践していくとなると、いくつかネックになってくるポイントがあります。開発者の皆さんにとっては、先ほどお話ししたような、コンピュータの速度で回る仕組みづくりができたら理想だと思います。ただ、それには必要な技術がたくさんあるんですね。
CI/CDまわりやIaC、コンテナビルド、モニタリングなど、いろいろなことをやらなければならず、クラウドネイティブな仕組みを1人でつくれる人は稀です。普通のエンジニアにとっては、認知負荷が高い状態になってしまうんですね。
最近は、その認知負荷の増大が課題になってきています。時間軸で見ると、2014年ごろから認知負荷が大きく跳ね上がっているのですが、2014年というのはKubernetesが誕生した年。そのころから、さまざまな技術が自動化できるようになり、良い技術が出てきましたが、それを活用するには頭のリソースを多く割かなければならない時代になりました。
草間：この認知負荷に対応していくために、最近ではプラットフォームエンジニアリングという分野が注目を浴びつつあります。クラウドネイティブ的なところを突き詰めていくと、人間の頭がボトルネックになってしまいますが、人間がいきなり能力を拡張することはできません。
そこで、クラウドネイティブ的な自動化を実現していくところをプラットフォームチームが担い、開発者の認知負荷を下げて、生産性の高い仕事に注力できるようにしていこうと。そうした取り組みが、プラットフォームエンジニアリングというカテゴリで進みつつあります。
こちらは、CNCFが出しているPlatform White Paperから持ってきた画です。例えば、IDまわりやCI/CDのような開発者の意識が取られがちなところを、プラットフォームチームがテンプレートやドキュメントを提供するアプローチで助けていく。それによって、開発者がスムーズに仕事ができるようにするという考え方ですね。
ということで、ここまでクラウドネイティブの本質と、クラウドネイティブの実践に必要なプラットフォームエンジニアリングのアプローチについてお話ししました。
自動化で生産性を高めながら、どう信頼性と両立していくか
草間：最近『エレガントパズル』という本が出たのですが、この本の冒頭にこんな一節がありました。「障害のほとんどはデプロイによって引き起こされる。したがって、デプロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポストモーテムが必要になる」というものです。
これを読んだのは、ほんの数週間前なのですが、ここから先の登壇スライドをこれに合わせて全部書き換えるくらいには、腑に落ちた表現でした。これは実際に、自分の感覚と合っています。システム障害もありますが、やはりアプリケーションをデプロイして、何か変更を加えたときに最も障害が起きるんですよね。
草間：セッション前半では、APIを使って自動化し、生産性を高めてどんどんデリバリーしていこうといった話をしてきました。もちろん生産性を高めることは非常に大事なのですが、それをすると何が起きるかというと、それだけ障害が起きる可能性が高くなります。だからといって、障害の数を減らすために回転を遅くしたら、本末転倒ですよね。
となると、生産性を高めるには、障害が起きないように対処していく必要があります。なので、信頼性を高めていこうという話になるのですが、大方針として、やはりクラウドネイティブ思考を尊重していきたい。では、そのうえでどうしたらいいでしょうか。
ここで障害を4つに分類してみました。縦軸が顧客影響があるかないか、横軸が予測可能かどうかです。左下は予測可能であり顧客影響がない、つまり通常の状態ですね。あるいは、何か起きているとしてもコントローラブルで、あまり気にする必要がないものです。
左上の予測可能で顧客影響があるものは、あまりないように思いますが、あるとすれば計画メンテナンスでしょうか。右下は予測不可能な事態だけれども、顧客影響がないということで、優先度が比較的低いシステム障害と言えます。そして、右上の顧客影響があって予測不可能なものは、インシデントと呼ばれるものですね。
草間：まず、左下に関しては、どんどん自動化して生産性を高めていくべきでしょう。ですが、予測不可能なものはどうやっても自動化できません。右上のインシデントに対しては、現在の技術ではまだ対処を自動化するのは難しいので、人間が対処する必要があります。大事なのは、素早く人間が気づき、素早く直していけること。これがインシデント対応の取り組みになります。
PagerDutyの話をさせていただくと、素早く気づくところに関しては、冒頭で説明したエンジニアを呼び出すオンコールでのインシデント対応の仕組みが役に立ちます。担当者のスケジューリングもできるので、オンコールに悩んでいる方がいれば、ぜひ試してみてください。
加えて、素早く直していくことも重要です。今まで経験したことがないトラブルだった場合、切り分けながら対応していくことになりますが、「前にも似たようなインシデントがあったな」という場合も多くあると思います。
PagerDutyでは、いろいろなモニタリングシステムからのアラートを蓄えていて、過去の類似インシデントが表示されます。過去のインシデントで、どのような対応をしたかという履歴も見ることができるので、対応するエンジニアが違ったとしても、それを参考に素早く対処していくことが可能になります。
また、特にマイクロサービスの世界では、自分が見ているプログラムに問題がなくても、他サービスの影響を受けてインシデントが起きることも多くあります。PagerDutyでは、他サービスで今どんなインシデントが起きているか表示されるので、そこから辿って素早く対処することができます。
草間：次に、運用側の普段の取り組みとしては、やはり顧客影響が起きないようにしていくことが一番大事です。計画メンテナンスも、金融機関のサービスなどではまだよくあったりしますが、事前にわかっているとはいえ、なるべくずっと動いている状態にできた方がよいでしょう。
これについては、ソフトウェアのアーキテクチャに手を入れて、停止せずに運用できる仕組みをつくっていく必要があります。クラウドネイティブ技術を活用しながら、アーキテクチャを変え、影響なくメンテナンスできるようにしていくことが大事です。
あとは、自動化ですね。クラウドネイティブ技術も含め、適切に自動化していって影響を減らしていきましょう。もう1つ、軽減策と書きました。予測不可能な障害であったとしても、顧客影響がないように自動的に対処していくことで、ユーザーへの影響を軽減することができます。
草間：そのためにどうしていくかですが、PagerDutyにある機能を紹介させてください。PagerDutyが買収したRunbookというオープンソースの自動化ツールがあり、それをもとにしたPagerDuty Runbook Automationという機能があります。ブラウザ上からワークフローを定義して実行できるツールで、いろいろなやり方で呼び出すことができ、さまざまなインフラやツールとの連携が可能です。
草間：例えばシステム障害があったとき、まず最初にエンジニアはどういうことが起きているのか、いろんなコマンドを叩いたりして切り分けをしていきますよね。その切り分けで行うことが決まっているのであれば、この機能を使って自動的にスクリプトを流す設定が可能です。
なので、先ほどアラートを受け取ってエンジニアを呼び出す機能の話をしましたが、その前に一段階挟んでおけば、呼び出したエンジニアが対処に取り掛かるころには、ある程度切り分けの結果が表示されている状態にでき、切り分けの時間を短縮できます。
あとは、自動修復ですね。ものすごく単純な例で言えば、再起動するとか。自動的に対処できるような軽減策を仕込んでおけば、それだけ精度の高い運用ができるようになります。
草間：そして、その後に大事になってくるのが、なるべく予測可能なものにしていく取り組みです。ここまで自動化について話してきましたが、予測できないものを自動化することは基本的にできませんから、難しい世界です。ここで何が大事なのかというと、ナレッジを溜めていくことです。
インシデントというのは、どうやっても起きるときは起きます。大事なのはインシデントが起きたとき、収束後に学びを得ること。SREのプラクティスに、ポストモーテムという取り組みがあります。なぜそれが起きたのか、どのくらい影響を及ぼしたのか、どういう経緯でどう対処したのか、再発を防ぐにはどうすべきか、といった内容をレポートにまとめるものですね。
予測不可能な世界で知見を集め、継続的な学びを得ていくことで、予測可能にしていく取り組みです。このあたりはまだまだ人間的ですが、大事な取り組みだと思っています。ポストモーテムによって学びのループを回していくと、組織やチームとしての成長につながります。
草間：PagerDutyを使っていただくと、ポストモーテムの作成も楽になります。ポストモーテムでは、事実を並べていく作業が面倒なんですよね。例えば、何時何分にアラート上がって、誰が対処し始めて、Slackでこんなやり取りがあって、どう対応して何時何分に収束したという内容を、あちこちのログからコピペしていくという、すごく単調な作業になりがちです。
PagerDutyでは、アラートや対応のログが自動的に蓄えられます。さらに、Slackのチャンネルを自動生成でき、そのSlackチャンネルでの会話も全部トラッキングされているので、収束後にレポートを書く段階でSlackの会話も一覧に表示されます。なので、レポートに載せたいやり取りがあればクリックするだけでよく、地味なレポートを書く作業がとても楽になります。
草間：また、今は生成AIの時代ですから、PagerDutyにもGenAIという生成AIの機能があります。それを活用すると、ポストモーテムのレポートもドラフトが自動的に生成されるので、これまで数時間かかっていた作業がほんの数分から十数分になったりします。
そうやって面倒な部分を解消しつつ大事な取り組みを続け、チームとして対応して運用の成熟度を高めていくことが、信頼性の向上につながります。
今日お話してきたメッセージは、クラウドネイティブ的な考え方、プラットフォーム的な考え方で生産性を高めていきましょうというものでした。ただ、忘れてはならないのが、自動化を進めていくにあたって、必ず運用上のひずみが出てくるということです。
それに対処するには、前提としてクラウドネイティブな自動化の思考を持ちつつも、人間が頑張ってチームとして対応していく必要があります。それを助けるツールとして、PagerDutyが非常に便利であるということが、お伝えしたかったポイントです。
草間：最後に繰り返しになりますが、クラウドネイティブの時代においては、コンピュータの力でコンピュータを動かす考え方、人間の関与をなるべくなくしていく意識が大事です。インシデント対応も、人間の関与をなくして自動化できれば理想ではありますが、生成AI時代とはいえ、現時点ではまだそこまで辿りついていません。
なので、未来の技術には期待しつつも、インシデント対応の力を高めていきましょう。ということで、私のセッションは以上になります。ありがとうございました。
アーカイブ動画も公開しております。こちらも併せてご覧ください。
