クラウドファーストの利点とは? クラウドの普及が本格化し始めた数年前に、「クラウドファースト」という言葉は登場してきました。 これはシステムを構築する際、「クラウドで動かすことを優先して検討する」という意味を指しています。 例えばオンプレミスでシステムを構築する場合、システムが稼働してからサーバーの性能を増大させたり、ストレージを高速化させたりすることは難しいため、キャパシティプランニングとしてシステムに必要な処理能力をあらかじめ予想し、その能力をある程度上回るサーバーやストレージを最初から用意する必要があります。 そのうえでハードウェアを調達して構築するといったコストと手間が構築時に必要となります。 一方のクラウドは、システムが稼働したあとでも、インスタンスの能力を増やしたり、ストレージを追加したりといったことが比較的柔軟に行えます。 そのため、比較的小さめのインスタンスやストレージを調達してクラウド上でシステムを稼働させたあとで、性能が必要になる場面で適切な大きさのインスタンスや高性能なストレージへ切り替えればよい、ということになります。 これにより綿密なキャパシティプランニングに時間をかけることなく、ハードウェアの調達も不要なため、迅速かつ低コストにスタートができ、万が一システムが不要になっても、ハードウェアの減価償却を待つことなく、すぐにシステムを破棄できるといったことが可能になるわけです。 以上が、一般的にクラウドファーストによる利点とされています。 そのクラウドネイティブを推し進めている団体「Cloud Native Computing Foundation」(CNCF)は、Kubernetesなどのさまざまなオープンソースソフトウェアの開発を進めています。 同団体はクラウドネイティブの定義として「」という文書を公開しています。 一部を引用しましょう。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ クラウドネイティブ技術は、、、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ やや抽象的な表現ですが、クラウドネイティブでは仮想マシンではなく、より粒度の細かなコンテナをベースとします。 それにより、よりスケーラブルで柔軟なアプリケーションが構築でき、クラウドファーストよりもさらに踏み込んだクラウドのメリットが得られるというわけです。 そのうえで、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIなどのテクノロジーを用いると、より効率的にクラウドネイティブなシステムが構築できることが示されています。 もちろんクラウドネイティブという言葉は、さまざまな組織や団体、個人が場面に応じて、さまざまな意味で使っています。 CNCFの定義はその1つでしかありませんが、概ねITエンジニアによる狭い意味でのクラウドネイティブの定義として、コンセンサスがとれつつある定義だと思います。 マイクロサービスやサービスメッシュについては、以前の記事「」で説明していますが、改めて整理しておきます。 マイクロサービスとはシステムを細かい「サービス」に分解し、それぞれのサービスを連携させることでシステムを機能させるというものです。 サービスに分解することで、サービスごとに負荷分散やスケーラビリティを持たせることができ、機能追加や機能変更も可能になり、万が一、あるサービスに障害が発生しても、その影響を局所的に抑えることができるといったことが可能になります。 それぞれのサービスはそれぞれのコンテナに割り当てられ、その上で稼働します。 あるサービスへの負荷が高まれば、そのサービスのコンテナの数を増やします。 こうした複数のコンテナを1つのシステムとして管理する仕組みがコンテナオーケストレーションツールとしてのKubernetesであり、コンテナ間の通信などを管理する仕組みがサービスメッシュであるIstioの役割です。 そして、コンテナ間の連携はサービスが公開しているAPIを介して行われるため、APIの定義を宣言するとAPIが生成される「宣言型のAPI」が用いられることになるわけです。 イミュータブルインフラストラクチャとは、直訳すると不変なインフラという意味です。 これを手短に説明すると、OSなどのインフラにパッチを適用するといった変更が必要な場合、変更作業を実行するのではなく、変更後のOSを用いた環境を新たに立ち上げ、古い環境は捨てるということであり、アプリケーションにとってインフラは起動時から終了時まで常に固定されている、不変であるということを指しています。 こうした柔軟なリソースの確保や破棄が可能なのは、クラウドが持つ柔軟性だからこそであり、イミュータブルインフラストラクチャとは事実上、こうした柔軟なリソース確保が可能なクラウドのことを指すのです。 例えば複数のサービスから構成される複雑なアプリケーションのビルドやデプロイは、手作業でやるのではなく自動化させたいところです。 そして、こうしたクラウドネイティブなツールを使いこなせるチームは、自ずとアジャイル開発手法やDevOpsといった、より柔軟な開発および運用のスタイルを採用することになるのではないでしょうか。 クラウドネイティブのハードルは非常に高い クラウドネイティブとはどのようなものか、その概要をざっと説明してきました。 こうしてみると、クラウドファーストに対してクラウドネイティブの実現は極めてハードルが高いものと言えるでしょう。 アプリケーションのアーキテクチャをマイクロサービス化し、コンテナやKubernetesなどを取り入れ、さらに開発プロセスに自動化を取り入れ、そうした開発に親和性のあるような開発組織と文化を作っていくという、組織からプロセス、設計、実装という、非常に幅広い領域に影響するのです。 逆に言えば、クラウドのメリットを徹底的に取り入れようとすると、これだけ大きな変化が求められるということでもあり、これが実現できる組織とそうでない組織では、(もちろんクラウドのメリットを得る手段としてクラウドネイティブがすべてではないものの)得られるメリットにおいて大きな差が出てくるということでもあります。 つまり、クラウドネイティブの実現は企業の情報部門だけに任せられる課題ではなく、企業文化そのものに対する課題も含まれており、その実現には経営陣のコミットメントなしに容易には成し得ないと言えるでしょう。
次のクラウドネイティブ・アプリケーションは、疎結合された小型で独立したサービスの集合です。 ユーザーからのフィードバックを継続的改善に速やかに取り入れる機能など、の提供を目的に開発されています。 つまりクラウドネイティブ・アプリケーション開発とは、新規アプリケーションの構築を迅速化し、既存アプリケーションを最適化して、手段です。 その目標は、ユーザーが希望するアプリケーションをビジネスニーズに応じて提供することです。 それでは、クラウドネイティブ・アプリケーション開発の「クラウド」とは何でしょうか?アプリケーションが「クラウドネイティブ」である場合、プライベート、パブリック、ハイブリッドの各種クラウドで一貫した開発と自動化された管理を実現することを目的に設計されています。 企業はを採用することで、アプリケーションのスケーラビリティと可用性を向上させることができます。 こうしたメリットは、セルフサービスによるリソースのオンデマンド・プロビジョニングや、開発から本番稼働までのアプリケーション・ライフサイクルの自動化によって実現します。 しかしこれらのメリットを完全に活用するには、新しい形態のアプリケーション開発が必要です。 このニーズに応えるのがクラウドネイティブ開発です。 アプリケーションの構築とアップデートを迅速に行い、品質改善とリスク低減も同時に実現するアプローチです。 具体的には、応答性と耐障害性に優れたスケーラブルなアプリケーションを、パブリック、プライベート、ハイブリッドのいずれのクラウド環境にも構築する方法です。 必要なのは、組織内の人材と、コラボレーションをサポートする自動化プロセスです。 つまり、 によって、開発チームと運用チームが共通の目的のもと、定期的にフィードバックを行う体制を作ることで、2 つのチームを連携させます。 を採用すると、アプリケーション・デプロイ・ユニットと自己完結型実行環境が理想的な形で実現し、こうした手法がサポートされます。 DevOps とコンテナを利用すると、大規模な 1 つのリリースの完成を待つのではなく、のような疎結合のコレクションとしてアプリケーションをリリースしてアップデートするほうが容易になります。 クラウドネイティブ開発は、アーキテクチャのモジュール性、疎結合、サービス独立性に主眼を置いています。 各マイクロサービスは、ビジネス機能を実装して固有のプロセスで実行し、 API またはメッセージングを通じて通信します。 この通信は層を通じて管理できます。 ただし、クラウドネイティブ・アプリケーションの一環としてアプリケーション提供をスピードアップするには、マイクロサービスの導入から始めなくてはならないわけではありません。 多くの組織は、実用的でサービスベースのアーキテクチャを使用してもレガシーアプリケーションを最適化できます。 クラウドネイティブ戦略の第一の利点は、コンピュート・リソースが複数の環境に分散している企業が、アプリケーション開発の速度を向上できることです。 たとえば、リソースの一部を Amazon サーバーと Google サーバー、オンプレミスで実行する Oracle データベースに収容することができます。 クラウドネイティブ開発を採用すると、このようなハイブリッドクラウド・アーキテクチャからさらなる価値を引き出せます。 ただしそのためには、クラウドネイティブ戦略の一環として実行すべき追加の手順があります。 サーバーレスとは、アプリケーション開発者がサーバーのプロビジョニングやアプリケーションのスケーリングの管理を行う必要がない、クラウドコンピューティング・モデルです。 このモデルでは、定型作業がクラウドプロバイダーによって取り除かれているので、従来のモデルよりも開発者がコードをプロダクションに移行するスピードがはるかに高速になります。 、、、さらには酪農まで、アプリケーションをビジネス戦略の中枢に置くソフトウェア企業でもあります。 このソフトウェア駆動型のビジネス変革には、新しいアプリケーションを迅速に開発し、提供する必要があります。 しかもユーザーはさらに高い品質を求めるようになっています。 これは簡単な仕事ではありません。 Red Hat では、現代の変化の激しい市場で競争に勝つには、プロセス、インフラストラクチャ、アーキテクチャへの投資が必要だと考えています。 このような課題の解決を支援するため、Red Hat は、アーキテクチャ、インフラストラクチャ、プロセスへの改善を実現するには新しいプラットフォームが必要だと考えています。 最終的な目標は、高品質のアプリケーションをさらに俊敏に提供できるようにすることです。
次のエキスパートたちが語るクラウドネイティブの今 新野淳一氏(以下、新野):よろしくお願いします。 今日のテーマは「クラウドネイティブ」です。 あとで僕も含めてみなさんに自己紹介をしていただくんですが、エキスパートの方が揃っていますので、非常に濃いお話を聞けるんじゃないかなと思います。 これから70分ちょっとぐらいパネルディスカッションをしていくパネリストの方々に自己紹介いただきたいと思います。 私の隣に座っていらっしゃるのが青山さんです。 よろしくお願いします。 (会場拍手) 青山さん、簡単に自己紹介をお願いできますか? 青山真也氏(以下、青山):はい。 クラウドネイティブっぽい格好で来てしまいました。 (会場笑) サイバーエージェントの青山と申します。 ふだんはサイバーエージェント内のオンプレミスにあるKubernetes as a Service、いわゆるManaged Kubernetesを提供するようなサービスのプロダクトオーナーをしております。 Kubernetes関連のアーキテクチャの相談も受けたりしています。 コミュニティ活動もしているので、クラウドネイティブの最新の情報や、国内海外問わず、どんな使い方をしているか、実際どうやって使われているかも追うようにしております。 新野:たぶん日本で大規模にKubernetesのクラスタを運用している会社は、そんなにないと思うんですよ。 青山:そうですね。 新野:その中で、青山さんは実際にやっていらっしゃる方なので、非常に実践的なお話が聞けると期待しています。 よろしくお願いします。 青山:よろしくお願いいたします。 (会場拍手) クラウドに特化したブティック型SIer 新野:そのお隣が荒井さんです。 よろしくお願いします。 荒井康宏氏(以下、荒井):よろしくお願いします。 クリエーションラインの荒井と申します。 一応役職上はCTOということになっておりまして、ふだんは社業全般をいろいろやっているんですが、 とくに最近力を入れているところとしてはチーム育成です。 アジャイルの開発チームをお客様と一緒に作って、そこでデジタルイノベーションといいますか、新しい価値を生み出していく活動をやっています。 ヘッドハンティングにも、ものすごく力入れてますので、興味ある方は懇親会でよろしくお願いいたします。 新野:クラウド時代は本当に人材の獲得競争が激しいですもんね。 荒井さんが所属しているクリエーションラインに関して僕が知ってることを補足すると、いわゆるブティック型のSIerと言えばいいんですかね。 専門にある程度特化して、とくにクラウド関係に特化した、こう言っちゃなんですけど比較的小規模なSIerですよね。 クラウドネイティブ界隈では比較的有名なんですけど、全国的にはブティック型のSIerで通っている感じですね。 荒井:そうですね。 新野:よろしくお願いします。 (会場拍手) IBM Cloudのテクニカルエンジニアの仕事 新野:そのお隣がアイ・ビー・エムの安田さんです。 安田智有氏(以下、安田):こんばんは、安田です。 ふだんはIBM Cloudのテクニカルエンジニアをしています。 具体的には、お客様のところに行って技術的に説明をしたり、営業が太刀打ちできないテッキーなお客様が来たら一緒に行って対応する役回りをしております。 問題が起こると最初に謝りに行く役ですね。 (会場笑) マネージャーもやっていますので、謝りに行きます。 最近、謝る回数がすごく減ってストレスが減っています。 弊社も人材大募集しておりますので……そういう場じゃない? そういう場じゃないですね。 すみません(笑)。 弊社はエンジニア集団なんですね。 なので、新しいテクノロジーを、英語で発信されることが多いので、それを日本のお客様向けにわかりやすく指南していく仕事もしています。 よろしくお願いします。 (会場拍手) 新野:今の話で印象的だったのは、クラウドが落ちるとアイ・ビー・エムさんは謝りに来てくれるんですね。 安田:「謝りに来い」というお客様が……。 新野:謝りに来ないクラウドも多いらしいじゃないですか。 荒井:普通は謝りに来ないですよ。 新野:荒井さん、普通、謝りに来ないですよね? 荒井:いや、普通は行かないです。 私の理解だと、クラウドはSLAに書いてあるとおりなので謝りには来ないと思いますよ。 普通に返金されて終わりだと思う。 そこはアイ・ビー・エムさんはさすがだなと思います。 新野:こんなメンバーで今日はディスカッションしていきたいと思います。 Publickeyの運営者、新野氏の経歴 新野:私の自己紹介を忘れてました。 私は「」というブログをやっております新野といいます。 10年ぐらい前までは今日の主催の「」の編集部にいたんですが、独立してフリーランスで「Publickey」というクラウド系の話題をよくブログに書いています。 AWSの「re:Invent」の最中だったので、今は夜中1時ぐらいからストリーミングを見て4時ぐらいまで見終わったら、朝7時ぐらいまで記事を書いてるという、今週はそういう生活でした。 最近、「Publickey」でクラウドネイティブの記事を書いたかなと思って、振り返ってみました。 3つぐらい挙げると、GoogleでCloud Runというサーバレスでコンテナを動かすものが正式版になったほかに、GitHubのActionsという機能が正式版になって、DevOpsを自動化することがGitHubでできるようになった。 Cloud Native Computing Foundationが、サーバレスを起動するときのイベント「CloudEvent」の標準仕様を作ったので、今までサーバレスはベンダーごとにバラバラだったんですけど、もしかしたら標準化が進むかなと思います。 こういう話題が最近クラウドネイティブっぽいなと思って挙げてみました。 こんな記事をふだんは書いております。 よろしくお願いします。 (会場拍手) クラウドネイティブの定義 新野:今日は3つのアジェンダを用意しています。 1つ目は「クラウドネイティブとは何か?」をみなさんにおうかがいしたいと思います。 もしかしたら人によってクラウドネイティブと言うときに、頭に思い浮かべているものや手を動かして作るものが違うかもしれないので、それぞれ「クラウドネイティブって何だろう?」を改めておうかがいします。 その上で、「クラウドネイティブを実現する上で、それはどんな技術から構成されているのか?」「何を買えばクラウドネイティブになるのか?」「お金を積んでもできないものがあるんですか?」などを聞いていきたいと思います。 3つ目は、そういうふうにクラウドネイティブの具体的な姿、あるいは技術的な姿が見えてきた上で、「それを実際に手に入れるにはどんな課題があるんでしょう?」というお話をみなさんとしていくつもりです。 というわけで、一応クラウドネイティブには世の中に定義があるらしいんですよ。 その定義は、Cloud Native Computing Foundationという独立団体があって、もともとGoogleがKubernetesをオープンソース化したときにそのオープンソースの開発を主導するために作った独立的な団体なんですけど、そこがクラウドネイティブの定義をGitHub上で公開しています。 このオフィシャルな日本語訳もあってコピペしてもらったので、読んでみますね。 「クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります」。 「これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます」。 というのがCloud Native Computing Foundationという団体が定義した「クラウドネイティブとは」です。 一応これをクラウドネイティブと言ったときの一番狭い意味の定義だと私は捉えています。 もう少し広くクラウドネイティブを捉えると、クラウドで作ればクラウドネイティブなんじゃないのか? ということはたぶん一番広い定義だと思うんですよ。 仮想マシンでもクラウドネイティブは作れる? 新野:そこの「クラウドを使えばクラウドネイティブじゃん?」というところから……要するにKubernetesやIstioやマイクロサービスなどを選択することがクラウドネイティブで、こういうメリットがあると書いてあるんですけど。 その中で、クラウドネイティブと言ったら「何だと思いますか?」と青山さんから聞いていきたいと思います。 どうですか? 青山:私自身はこの文章に対して、だいたい8割ぐらいはおおむね同意です。 違うと思うのが、いろいろ途中でコンテナやサービスメッシュ、マイクロサービスと出てきますけど、これはやはり必須ではないんですね。 「アプローチの代表例に」と書かれているので。 なので、この文章をだけを見て誤解を受けちゃう人は多かれ少なかれいるかなと思っています。 VMを使ってマイクロサービスっぽくて、ミニサービスぐらいのアーキテクチャでサービスを作ったときにクラウドネイティブではないかというと、私はそれぐらいならクラウドネイティブかなと思っています。 新野:なるほど。 仮想マシンでもクラウドネイティブは作れる。 その心は? 青山:その心は、結局クラウドネイティブは、クラウドを使ってサービス開発してきて、それのベストプラクティスを文言化したものだと思うんですね。 そのベストプラクティスなシステムが何かというと、回復力・管理性・可観測性・更新容易性があるなどの特性を持っているシステムが作れている状態、またはそれが作れている組織の状態を目指せればいいので、それは別にVMでもできるものかなと思っています。 新野:なるほど。 ということは、青山さん的にはこの2段目の最初にある回復性・管理力・可観測性・更新容易性のある疎結合的なシステムが一番大事だと思っている? 青山:はい、そうですね。 なぜ「可観測性」が重要なのか? 新野:もう少し詳しく聞いてもいいですか。 回復性・管理力・可観測性って何ですか? 青山:回復性は、システムを作ったあとになにかが起きたときは、一番ダメなシステムだと「アラートが来たら手動で復旧する」みたいなものが多いと思うんですが、クラウドネイティブな世界ではすべてそこが自動化されている。 なにか起きたら特定の手順をやって、自動的に復旧されるようになっていることなどが回復性ですね。 管理力も近しいと思うんですが、管理がしやすい状態であるというところ。 例えばたくさんVMがあったときに、どれがどれだかわからない状態にならないように適切な自動化ができている状態。 可観測性はどこで何が起きているか正しく把握できる状態。 ごちゃごちゃしてきたときにも、こことここで何があったなら、そこの通信もちゃんとトラッキングされていて、管理しやすいという話にも近いとは思うんですが、そこの詳細に追っていけるようになっている状態ですね。 新野:なるほど。 たぶん最後の可観測性が一番最近出てきた言葉というか、あまりこれまで使われなかった言葉だと思うんですけど、可観測性とは何ですか? 青山:例えばクラウドネイティブをやっていくにあたって、組織が非常にデカくなってくると、やはりマイクロサービスなアーキテクチャにしていかないと、もう開発が進まなくなってきちゃうんですね。 なので、マイクロサービス化しますと。 例えばTwitterさんだと数千マイクロサービスになってくるので、それらの通信はマイクロサービスにした瞬間に可観測性が落ちちゃうんです。 どこで何が起きているかが一切わからなくなっちゃうじゃないですか。 新野:モノがあまりにも動いているので、どこで何が起きているかがわかりにくくなってしまう。 そういうことですね。 青山:そうです。 5,000個のサービスごとにそれぞれフルメッシュの通信があったとすると、もう5,000の階乗ですかね。 新野:たぶんそんな量ですね。 青山:この通信を全部把握するのは難しくなってくるので、そういったときに巷で話題のサービスメッシュを入れると、ちゃんとそれぞれの通信もトラッキングできるようになります。 こういったものでいわゆる可観測性を担保するのが最近の流れだったりします。 新野:なるほど。 マイクロサービスアーキテクチャとクラウドネイティブは分けるべき 新野:青山さんが大事だと思っていることはなんとなくわかってきました。 次に荒井さんの意見を聞いてもいいですか? 荒井:私は青山さんの言うように、割合で例えると、だいたい2割ぐらい合意です。 ごめんなさい。 新野:いや、いいですよ。 違う意見のほうが楽しい。 荒井:すみません、あえて言います。 「マイクロサービスアーキテクチャとは?」と書いてあったら、80~90パーセント合意と言うんですけど、クラウドネイティブという言葉が広すぎますよね。 「クラウドネイティブって、クラウドをネイティブに使ってたらクラウドネイティブになるんじゃないの?」と言われると「ぐっ……」って来ちゃうので(笑)。 新野:そうすると、マイクロサービスとクラウドネイティブは明確に違うわけですよね? 荒井:個人的には「マイクロサービスアーキテクチャ」という言葉と「クラウドネイティブ」は分けたほうがいいと思いますね。 自分の考えるクラウドネイティブは、クラウドを使っている歴史が私は長いので、まずフェーズがいくつかあると思っていて。 最初のフェーズはAmazon S3がクラウドネイティブだと思っています。 完全にそれは単体のサービスで、ファイルを置くだけでWebサーバができ、コンテンツのデリバリーができる。 「これはもう完全にクラウドの中で閉じてるじゃん。 別に開発環境とかいらないじゃん。 もう手元の環境いらないじゃん」という意味で、これはクラウドネイティブ以外の何者でもないなというのが自分の印象です。 さらにクラウドの機能が発達してきて、イベントドリブンとデータドリブンがクラウドの中で、VMの中で自分で処理しなくても、クラウドのサービスの機能を使うだけでシステムができるようになった。 そこは第2のクラウドネイティブというのか、クラウドの進化のタイミングだったなと思っています。 クラウドの機能を活用する設計であることが大切 新野:ということは、もう少し僕なりに理解すると、クラウドっぽいサービスを使えば、クラウドっぽいサービスでできていれば、クラウドネイティブなアーキテクチャだったりクラウドネイティブなアプリケーションだったりすると思えばいいんですか? 荒井:本当に広く捉えるとそうなるんでしょうが、個人的に言うと、クラウドのマネージドなサービスをフルに利用して、自分自身で開発するところが極小化されていて、なおかつ、オープンに複数のクラウドで同じようなアーキテクチャが使えることが個人的なクラウドネイティブなイメージです。 新野:なるほど。 例えば、「分散アプリケーションってクラウドっぽいよね」ってよく言うじゃないですか。 でも、今の荒井さんの話だと、業務アプリケーションをクラウドに持ってきて、データベースをマネージドサービスにして、ストレージもオブジェクトストレージにして、アプリケーションそのものは分散じゃなくてモノリシックなアプリケーションだけど、支えているのはクラウドネイティブなサービスです。 この場合はクラウドネイティブっぽい感じなんですかね。 荒井:うーん、自分的に言うと、そこは3割ぐらいかなみたいな。 新野:なるほど(笑)。 荒井:システムがデータドリブン・イベントドリブンで動いている状態と違うんですよ。 新野:そこが大事なんですね。 設計上クラウド的の機能を活用することは大事な要件だと。 荒井:そうですね。 私的に言うと、そういうクラウド的なところで、なおかつ、やはりイベントドリブン・データドリブンで処理が進んでいるところが重要なポイントかなと思います。 新野:なるほど。 イベントドリブンはなぜクラウドネイティブっぽいと思われるんでしょうね。 荒井:そこは重要なところなのかなと思っていて。 もともとの計算処理は基本的にはイベントドリブンで全部できると思っています。 なおかつ、イベントドリブンでやると、オンデマンドで必要なリソースを確保して、そのタイミングだけ処理させればいいので、ものすごくクラウドの思想というか、リソースの最適化とシェアリングにすごく合ってるんですね。 そういう意味で言うと、私はそういうことがクラウドネイティブのイメージに近いです。 新野:ありがとうございます。 これはこれで非常におもしろい。 荒井:これはあくまでも個人的な意見で、すみません。 お客様に対しては、クラウドネイティブのハードルを下げる 新野:安田さん、今まで守備範囲の違うクラウドネイティブのそれぞれの定義をおうかがいしてきました。 安田さん的にはどうですか? 安田:クラウドネイティブの前に、クラウドコンピューティングの定義はみなさん覚えてますかね? 仮想化・自動化・標準化とあったと思うんですけど、回復性を見ると、そこのクラウドコンピューティングのあの時の3つの単語がフラフラと浮かんできます。 「これってクラウドですよね?」とお客様から聞かれたときに、「この3つの機能を備えてますか?」と返します。 3つ揃ってないとバツなのか、「いや、自動化できているので、クラウドですかね」と言うことにすごく似てるんじゃないかなと思います。 クラウドコンピューティングの定義は、インフラだけにすごくフォーカスされていたと思うんですけど。 新野:そうでしたね。 要するに「このインフラはクラウドかどうか」という感じですね。 安田:クラウドネイティブとなると、組織だとかビジネスアプリケーションを動かすインフラにどういう機能が必要になってくるかまでに言及の範囲が広がっていて、利用者というかインフラを動かす人たちが「どういう機能が今後必要になってくるので、ちゃんとそこまで考えておきましょうね」という言い方が広まったと思っています。 なので、クラウドネイティブがどうなのかというと、たぶん私の表現はもっと違います。 クラウドコンピューティングをただ単に使うだけでも、お客さんからすると、今までオンプレでガチガチに固めてたインフラから、インフラをどう柔軟に使うかを考え、組織として変わろうとしているこの編成なので、それはクラウドネイティブなアプローチと言ってもいいんじゃないかなと。 お客様に「いや、それはクラウドネイティブじゃない」と言っちゃうと、ショボンとしちゃう。 「いや、アプローチは合ってます。 その延長線上にこんな世界があるんですよ。 1歩目はどこのお客様もこうです」という説明を僕らはしたい。 「クラウドネイティブとは?」と言われると、「いや、入り口は仮想化・自動化・標準化です」から始まっても十分いいんじゃないかなと思います。 新野:なるほど。 ハードルをすごく下げるわけですね。 安田:すごく下げる。 でも、多くのお客様の中ではすごくハードルが高い。 そういうお客様に対して、1歩目から「それはクラウドを使いこなす道ですよ」とお伝えしたいなと思います。 ITに対してわがままになれる技術 新野:安田さん、このあと2つ目のアジェンダでは「クラウドネイティブをどうやって作るんですか?」というお話をするんですけど、その前に「クラウドネイティブって何がいいんですか?」という話をしなきゃいけないと思うんですよ。 安田:そうですね。 新野:ここで定義はそれぞれ意見が分かれましたけど、クラウドネイティブに別に大したメリットがないなら議論する価値もないわけじゃないですか。 クラウドネイティブにどんな価値を感じているがゆえに、「これはクラウドネイティブである・これはクラウドネイティブでないから、クラウドネイティブのほうが価値があるんだよ」と見せなきゃいけないと思うので、クラウドネイティブの価値が何だと思うのかを逆に聞いていきたいと思います。 安田:そのクラウドネイティブ……「クラウド」というキーワードが出てきたときに、多くの利用者というかお客様が考えるのは、なにかを変えないといけない課題意識があって、コストがかかりすぎてる課題意識を持たれているお客様が多いんですけど、EOSが来るので、やはり次はもっと柔軟性のあるインフラにしたい。 新野:EOSとは、要するにサポート期限が来ちゃうことですね。 安田:サポート期限が来ちゃうので、「乗り換えるなら今だ」ということですね。 そこをトリガーにして、もっと柔軟にいろいろ便利な機能を使えるクラウドがあるに違いないことが、お客様に考えを変えるきっかけを与えていますよね。 クラウドネイティブというよりはもう少し範囲が広いかもしれない、こういったことがクラウドのテクノロジーのメリットなんじゃないかなと思います。 延長線上ではなくて、次の新しいことをなにかしなければいけないのを、きっかけを与えている技術の1つだと思います。 新野:それを少し技術的な面から教えていただけませんか。 技術的にはコストが下がるんですか? それとも安く上がるか、速くできるか、あるいは人に任せられて楽になるのか。 なにかクラウドのメリットは何でしょうか? ある意味、「これだからいいいんですよ」とお客さんに勧めるわけじゃないですか。 勧めないのかもしれないですけど。 安田:私もともとクラウドの仕事に行く前はハードウェアを専門に売るエンジニアをしてました。 逆の売り方をするチームに今います。 やはりどういう比較をお客様がしてくるかというと、やはりTCOで見るですね。 「買ったらいくら。 電気代いくら。 場所代いくら」みたいな。 「それをメンテナンスするときにどうなの?」と。 ただ、そこはなにも起こらないでずっと使い続けたときの比較はもしかしたら正しいのかもしれないんですけど、なにか問題が起きたときにどう対応するかとか、「いやいや、今使おうとしている業務が増えたらどうするの?」「減ったときどうするの?」をコストにするのはすごく難しいですよね。 新野:そうですね。 安田:それがクラウドのテクノロジーを使うと、必要な分だけ使えばいいし、いらなくなったら手離せばいい。 固定資産を持たなくていいんだという、費用面からの柔軟性がある。 「もっとITに対してわがままになっていいんですよ」「買ったから4年間使わなきゃいけないとか、そういうのはないんです」とよく言ってました。 新しい機能が出てきたら「試せばいいんじゃないですか」と、わがままを言えるようなものがメリットなんじゃないかなと思いました。 新野:クラウドネイティブにするとわがままが言いやすい。 安田:言いやすくなる。 ……あれ、大丈夫かな? 荒井:自分の首を絞めてる。 安田:謝る機会が増えるかもしれません(笑)。 (一同笑) クラウドネイティブのメリットとは何か? 新野:同じ質問をします。 荒井さんは、さきほどクラウドネイティブの定義がありましたが、そうすると何がいいんですか? 荒井:まず最初に重要なのはやはりスケーラビリティで、圧倒的な要求とかが来たときでも捌ききれる。 リソースが動的に場合によっては自動的に伸縮できるところはやはりものすごく大きいメリットかなと思っています。 もう1つは、スピードとも言ってもいいかもしれないですが、クラウドの高度なテクノロジーが簡単に使えるのはものすごいメリットだと思っていて。 例えば、AWSであれ、GoogleのBigQueryであれ、オンプレで作るのは不可能なシステムなんですね。 それが簡単に使える。 よくあんなに簡単に使えるなと思うんですが、そこは非常に大きいメリットです。 それによってシステム開発のスピードであったり、運用の楽さであったり自動化であったり、そういったメリットが出てくると思っています。 新野:だからおそらく2つあって。 そもそもオンプレミスでは何万台もサーバを組まないと実現できないようなことがあります。 しかも何万台もサーバを買うのは普通無理ですよね。 それがクラウドではできる。 ただ、それはクラウドを使えばいい話であって、もう少しクラウドネイティブっぽいメリットが聞けるとうれしいなと思うんですが、そこはどうですか? 荒井:そういう意味ではスケーラビリティの速度がものすごく重要だと思っています。 コンテナベースの技術によってスケールする速度がものすごく上がっているんですね。 おそらくApp EngineやBigQueryなどは、コンテナベースで処理するようになっていると思っているのですが、ものすごくスケーラブルで、オンデマンド性があるんですが、そういうところは非常にメリットになっているのかなと思います。 新野:確かにコンテナを使うと、仮想マシンよりは速く立ち上がったり消すのも簡単なのでスケーラビリティ上のメリットが非常にあって、そこはクラウドネイティブの大事なメリットであると。 荒井:大事なメリットだと思います。 新野:青山さんにも同じことを聞いてみたいと思います。 青山:はい。 クラウドネイティブだと何がいいのか。 新野:何がいいですか? というか、青山さんの会社はまさにクラウドネイティブっぽいインフラで運用してるわけじゃないですか。 そこには「クラウドネイティブじゃないよりもクラウドネイティブのほうがサイバーエージェントさんにとってよかった」という決断の下にやっていると私は理解しています。 何がよかったのかをぜひ教えてほしいんです。 青山:まず前提から言うと、インフラエンジニアとかSRE、アプリケーション開発者が使うプラットフォームで、一番実現したいことって何もしないことだと思うんです。 何もしたくない。 新野:無事に動いてくれればそれでいい。 青山:はい。 スケールもちゃんとしてくれて。 新野:ああ、そうか。 イベントをやったときにお客様が一度にたくさん来ても、なにもしなくてもかなり広がってくれる。 青山:スケールするし、落ちたときも自動で戻ってくれる。 それをうまいこと明文化したのがクラウドネイティブだと思っているんですね。 新野:なるほど。 青山:逆にクラウドネイティブってパッと出てきたものかというと、なにかの原点があって、クラウド化して、その先がクラウドネイティブだと思っています。 クラウドネイティブでなにもしない状態までいけるのかは定かではないんですが、そのなにもしない状態に向かって近づいていっている状態だと思うんですね。 それを目指しています。 なので、それがメリットですね。 お客さんの要望に応えると、クラウドネイティブになっていく 新野:荒井さん、今の青山さんのメリットを聞いてどう思いました? 荒井:完全にアグリーです。 そこの中で考えると、いわゆる運用が非常に楽だというところは非常にメリットだと思います。 なるほどなと。 さすが青山さんだなと思いながら聞いてました。 新野:荒井さん、SIerってお客様に対してもクラウドネイティブなシステムを売ることはありますよね。 荒井:もちろん。 新野:今、「クラウドネイティブ欲しいんだけど」って言うお客さんって、何を欲しがってると思います?これは安田さんにもあとで聞きます。 荒井:クラウドネイティブを欲しがっているわけじゃなくて、開発のスピードと、そのあとのマネジメント、運用の楽さなどが、結局のところお客さんの価値であって、クラウドネイティブだけお客さんに届ければ解決するのかというと、そんな感じではないですよね。 新野:なるほど。 楽な運用がしたいときに、「いいものがありますよ。 クラウドネイティブというものがあります」という感じになるんですかね? 荒井:いやいや、それはやらないです(笑)。 クラウドネイティブを売る発想はなくて、届けたいのは要するにスピードと楽になることだと思います。 だから、クラウドネイティブで定義されているようなアーキテクチャを実際にはお客さんに提供しています。 ただ、それだけじゃなくて、さきほどGitHub Actionの話がありましたが、うちの場合だとGitLabを使っています。 あとは、お客さん自体の開発がうまく回らないときなど、そういう開発に対するアジャイルの支援であったり、そういったものを一緒に提供しています。 新野:今のが大事で、そういうお客さんの要望に応えていくと、ある意味結果的にクラウドネイティブに近づいていく。 荒井:そうです。 荒井:そうですね。 お客さんに提供するものにセットとして含まれていくかたちに今なっています。 クラウドネイティブに合わせて組織を変える覚悟はできているか 新野:安田さん、いかがでしょうか。 安田:お客様から「クラウドネイティブください」と言われることはほとんどないですね。 (一同笑) ただ、「クラウドネイティブを使うといろいろ開発が速くなるらしいね」「開発の効率が上がるみたいだね」というのは、お客さんもやはりいろんなところで勉強されているのでよくご存じですね。 「それをどうやったら実現できるんですか?」という質問は本当によく聞きます。 仮に開発をなにかやりたい、効率化したいというお客様がいらっしゃったとしても、どんなシステムなのか、どんなアプリなのかを聞くのは別にクラウドネイティブにはじまった話じゃなくて従来の要件定義なので、何が必要なのかをうかがいます。 いろんなやり方がありますが、クラウドネイティブは組織を変えるところがすごく大切なので、それに対してお客様が覚悟できるかどうか、「いろいろ変えないといけませんよね」という思いは打ち合わせをします。 長期的にそういうアプローチができるのであれば、「じゃあクラウドネイティブに向かっていきましょうか」と言います。 でも、そこに踏み切れるお客様はなかなかいらっしゃらなくてですね。 だいたい予算が1つの業務アプリに閉じていたりすると、「そこまで手間かけられません」となるので、やはり「モノリシックなもので、クラウドを使いましょうか」という結果になることも少なくはないです。 新野:そこにどういうハードルがあるかは、この次の次のアジェンダでまた詳しくおうかがいしようと思うので。 安田:勇み足でした(笑)。 新野:ここまでで、クラウドネイティブはそれぞれどういうものであって、それにはどんなメリットがあるかを少しみなさんとイメージが共有できたような気がします。
次の