第5回 読んでおきたい、SokoPの「Google Cloud 実践ガイド」
DXを支援するGoogle Cloudが提供する「市場の変化に素早く対応」できるクラウド環境
ビジネス変革に必要な選択肢、「オープンクラウド」とは？
みなさん、こんにちは。Google Cloudのパートナー エンジニア「SokoP」こと浦底（@urasoko）です。今回からは、9月14日～17日に開催された「Open Cloud Summit」でもフォーカスされた、市場の変化に素早く対応し、ビジネスの成長に合わせて柔軟に構築できるクラウド アーキテクチャ「オープンクラウド」の観点からGoogle Cloudのサービスを見てみましょう。
トランスフォーメーション クラウドの一翼を担う「オープンクラウド」とは
今年5月に開催された「Google Cloud Day: Digital '21」でも謳われていた「トランスフォーメーション クラウド」は、多く企業が取り組むDXにおいてビジネス変革を促進する新時代のクラウドビジョンと位置づけられています。
このトランスフォーメーション クラウドのビジョンに基づき、Google Cloudではビジネス変革を支援する4つのクラウド アーキテクチャを提供しています。これまでの連載で紹介してきた「データクラウド」、さらに「コラボレーションクラウド」「トラステッドクラウド」と並び、今回ご紹介するオープンクラウドもそのひとつです。
オープンクラウドでは、ビジネスの変革を推進するために選択肢、柔軟性、迅速性の高いソリューションを提供します。オペレーションやガバナンスなどのさまざまなサービスを、オンプレミスや複数のパブリッククラウド、エッジなどのさまざまな物理的場所に提供できます。それらを可能としているのがオープンソース技術です。Googleは長い間、オープンソースの世界においてリーダーシップを発揮してきました。そのオープンソースが、プラットフォームや環境を問わない、柔軟なアプリケーションの構築・実行やベンダーロックインの回避を可能にします。そのなかでもコンテナとオーケストレーションフレームワークである「Kubernetes」が、オープンクラウドのアプリケーション プラットフォームに活かされています。
オープンクラウドの説明には「市場の変化に素早く対応」とありますが、さらに視点を拡げるとポイントが2つあります。
1つ目のポイントは、対応すべき変化が「あらゆる変化」であるということです。市場の変化や顧客ニーズの変化といった外的要因だけではなく、業績や社内事情などの内的要因も含めた、あらゆる変動要素に対応できる必要があります。
そもそも事業とは、さまざまな変動要素に対してビジネスの優位性をもとに価値を生み出していくことです。年次、月次、日次、さまざまなサイクルや視点で定期的に、事業の見直しをされている企業様が大半でしょう。したがって「あらゆる変化」に対応しなければならないと言っても、何を今さら当たり前のことを……と思われるかもしれません。
ここで登場する2つ目のポイントが「素早く」です。定期的にさまざまな視点から事業を見直すのは当たり前としても、それが「素早く」対応できていると断言できる企業は、はたしてどれくらい存在するでしょうか。仮に、ある変化に対応するために業務プロセスを変更・改善したいという要望があった場合に、それが皆さんが望むかたちで実装されるまでにどのくらいの時間がかかるでしょうか。「それはケース・バイ・ケースだ」と結論を急ぐ前に、一歩引いた視点で考えてみます。
物体の動きが緩やかだと、ある観点からは止まって見える
ビジネス変革にゴールはあるでしょうか。先に挙げたさまざまな変動要素は、常に動き続けるものであり、対応し続ける必要があります。次に、対応の速度が変動自体を追随しきれていないとするなら、変化との乖離は進む一方です。仮に動いている物体があったとして、その物体の動きが緩やかであるなら、ある観点からはその物体は止まったも同然に見える。この感覚はみなさんもおわかりになるでしょう。
変化への対応が常に、素早く実現できるとするならば、すべての変化は予測対処可能であり、もはや変動要素とは呼べません。裏を返せば、いかなる変化に対応することもすべて受動的であり、かつ対応の効果を省みながら継続する必要があるということです。何かの変化に対して課題が明らかになった時点で、いつでも素早く対応が進まなければ、たとえどんなサイクルや手法で実施していても「変革は止まっている」と解釈され得るということです。
変革に必要な堅牢性／継続性／柔軟性と、オープンクラウドが備える可用性／可変性／可搬性
さまざまな変化に対し、可能な限り迅速かつ柔軟に対応するとしたとき、土台となる基盤が足かせになってはいけません。ここで、クラウド基盤とオープンクラウドが備える特性が活きてきます。
通常の事業を維持しながら変化に対応したり、対応に則して事業を停止したりする場合は、たとえそれが計画的なものであってもそのインパクトを計る必要があります。まして、不測の変動要素でサービスの提供自体が停止する場合のインパクトは計り知れません。
事業の堅牢性を担うことにクラウド基盤の可用性が活用されるわけですが、物理サーバーや仮想マシンが前提の構成と同様に、クラウド基盤にアプリケーションを構築した場合、OSやミドルウェアから上のレイヤーにおける運用は、原則として既存の運用レベルと同等、もしくは周辺のクラウド機能やサービス群で補完することでさらに高度な運用を実現できます。
そして、ここでオープンクラウドの重要な要素であるコンテナとオーケストレーションが、さらなる効果をもたらすのです。
継続的な変更を実現する基盤とフレームワークとアプリケーション設計
事業の継続性もさることながら、先に挙げたとおり、変化への対応にも「継続性」が必要です。継続的にアプリケーションを改修する場合に、改修の粒度を問わずアプリケーション全体に影響が出てしまうような設計では、迅速性が失われてしまいます。
コンテナによりアプリケーションの実行基盤が軽量化され、かつインフラ基盤から切り離される（抽象化される）ことにより、さまざまな機能の集合体として存在していた巨大なアプリケーションが、より細かい粒度のサービスとして管理できるようになります。これにより、アプリケーション全体に影響を出さず、改修する部分だけを迅速にリリースすることができるようになります。
これは、比較的リリース回数の多いWebサービスや“to C”のサービスだけに限った利点ではありません。少ないリリース回数で業務上充足していると考えられている事業のなかには、既存の基盤の制約やプロセスの煩雑さが原因で改修ができず、変革が難しくなっているものもあるでしょう。
細かい粒度で迅速にリリースできるということは、障害に対しても迅速に対応可能であるということです。さらに、リリースした新機能が期待にそぐわないものだった場合も、追加対応が迅速にできることはもちろん、安定稼働していた前バージョンへ迅速に戻すことも可能になります。この可変性が、結果的に全体のサービスレベルを高く維持し続けることにつながります。わかりやすく言い換えると、間違いがあった場合には素早く認知、対応することで、のちのち生じる取り返しのつかない状況を防ぐという、日常生活でもごく一般的なお作法と同じなのです。
コンテナでハイブリッドクラウド、マルチクラウド――その前に
また、コンテナの利点に「可搬性」があります。このメリットは特にハイブリッドクラウド、マルチクラウドで利用する場合に挙げられますが、それ以前に、先に挙げてきた継続的改善を実現する開発プロセスにおいても効果を発揮します。
コンテナがアプリケーション実行基盤として抽象化され、実際に動くインフラ基盤から切り離されることで、開発者の開発環境から、リリース前の検証環境、そして商用の本番環境までの定義が一貫して管理可能となります。さらに、それらは構成が固定された物理サーバーではなく、仮想マシンの起動イメージファイルのようなバイナリでもなく、「コード（可読文字列）」で定義されます。すなわち、アプリケーションのコードと同様に、リポジトリでバージョンも含めた管理が可能になるのです。加えて、コンテナイメージもリポジトリでの管理が可能です。これにより、開発に必要な環境準備に伴う作業と、テストを実施するうえでの検証環境の配備を、迅速かつ正確に実施できるようになります。
精度の高い機能を実装すべく、素早く細かくテストを繰り返し、結果を反映しながら開発してリリースする。ユーザーから要望のあった機能を、一部先行ユーザーにリリースし、フィードバックを得ながら、本当に求められていた機能を開発してリリースする。2つの仮説を想定した異なる機能をユーザーの半数ごとにリリースし、好評だったほうのリリースを“正”とする。こういった運用が可能です。
最後の例を読まれて「せっかく開発したコードがリリースされずお蔵入りになるのはどうも……」と思われる方もいらっしゃると思いますが、それは前出同様、暗黙の常識に引きずられているからかもしれません。ユーザーに真の価値を提供するために、テストされ、リリースされない機能を開発することに自身の工数を割いたエンジニア――。その貢献もまた多大なものなのです。
迅速にテストやフィードバックのサイクルを反復していくアジャイル開発は、精度が高く、本当にユーザーが求めているアプリケーションを、継続的に提供し続けるための手法です。決して多大なトラフィックが伴うサービスや、リリースサイクルが早いアプリケーションだけに閉じたものではなく、多くの業種や事業において活かせる可能性があります。
現状の基盤をコンテナ化していくうえで、アプリケーションの再設計やコンテナ技術の習得、また開発プロセスの習得と定着にはリスクとコストを伴います。しかし、それを乗り越えることで事業自体の向上につながり、アプリケーション利用者だけではなく、アプリケーション開発・運用チームも大きな利点が得られるのです。
オープンクラウドはすべてのユーザーの目の前ですぐに使える状態にある
みなさんの既存業務においてクラウド基盤やオープンクラウドを活かすうえで、あわせて見ていただきたいのが「Google Cloud Marketplace」です。ここから「Kubernetesアプリ」でフィルタをかけると、ひょっとしたらみなさんがお使いの、もしくはみなさんの業務に活かし得るミドルウェアが、すでにコンテナ化され、Kubernetesアプリに対応した形で公開されているかもしれません。こういったミドルウェアの活用とあわせて、クラウド移行、コンテナ基盤のメリットを運用に取り入れていくことも適切かもしれません。
オープンクラウドを活用するための最初の一歩は
クラウド基盤を活かすにも、コンテナ基盤を活かすにも、ご紹介したような視点でみなさんの現行の業務自体を見直し改善することが、オープンクラウド活用の第一歩となり得る可能性を秘めています。そのためには、まず現状の業務を細部までクリアに把握することです。そうしなければ、課題も改善点も見えてきません。そして、本質的にどのようなプロセスであればよいか、現プロセスの要否も含めて抜本的な議論と検討をする必要があります。
そして、それらに実効性を持たせるために最も重要なことは、経営層の判断のもと、正しい理解で、十分な予算化も備えた「正式なプロジェクト」として進めることです。既存業務を抱える部署に依頼して成果が実るものではありません。専門部署を立ち上げたとしても、目的や方向性、そして先に挙げた業務の見直し・改善への熱意が伴わなければ、進捗は見出し難いでしょう。
逆に言えば、適任と言えるのはそれらに熱意を持って臨んでくれる従業員の方々です。職位も役職も関係ありません。その適任者たちで組まれた最高のチームに、十分な予算と裁量を与え、今までにない視点で改革への一歩を踏み出してください。
そして、最高のチームのメンバーと一緒に、先行している事例をOpen Cloud Summitのアーカイブでご視聴ください。
また、トランスフォーメーションのサイクルを始められたみなさんは「Google Cloud Next '21」にご参加いただき、最新情報もご活用ください。