ITマネジャーはクラウドネイティブ思考をどう活用すればいい？：DXに悩むITマネジャーにささげる！ クラウドネイティブ講座（2）
本連載では、忙しいITマネジャーのために、クラウドネイティブを本質から解説している。第1回は「クラウドネイティブ思考」を解説したが、今回はそれをどう活用できるかについて、例を使って説明する。
「DXに悩むITマネジャーにささげる！ クラウドネイティブ講座」の第2回です。第1回では、技術の進歩により人間の力だけではITインフラの運用が困難になりつつあること、そして打開するためにはコンピューターの力でコンピューターを動かしていく考え方が重要になってくることを説明しました。そして、こうした考えのことを『クラウドネイティブ思考』と名付けました。
今回は、このクラウドネイティブ思考をどういうケースで活用すべきか、例を用いながら解説していきます。
物事を、コンピューターが実行できるように分解していく
第1回で解説したとおり、クラウドネイティブ思考で大事なことは「コンピューターの力でコンピューターを動かす」「人間の関与をなくしていく」の2点です。この考え方を常に心にとどめておき、あなたのあらゆる業務に対して適用できないか考えていきましょう。
最初は活用方法がうまく思いつかないかもしれません。「○○の仕事はコンピューターに置き換え可能だろうか？ いや、難しそうだ」となってしまい、結局人間がやったほうがよさそうだという結論に至ることが多いでしょう。
それはもしかすると、普段から人間中心の考えをしているからかもしれません。
コンピューターがその速度を発揮できるのは、コンピューター向けに作られたタスクを与えられたときのみです。複雑なタスクをコンピューターが自らの意思で分解し、最適な形で実行していくのは、少なくとも現在の技術では困難です。
一方、人間は複雑な思考を得意とし、抽象的なタスクであってもうまく解釈してこなすことができます。結果として、「○○の仕事は人間じゃないとダメそうだな」となるケースが多くなります。しかし、筆者はここに落とし穴があり、システムの改善が進まない原因になっていると考えています。
「人間しかできないから人間がやる」のではなく、「仕事をよりシンプルにして、コンピューターで実行可能な形にする」ことが重要です。
具体的な例で考えてみましょう。
モデルシナリオ
あなたがITマネジャーとして、社内向けの新システムに関わっていたとします。新システムはアプリケーションサーバ数台とデータベースサーバ、キャッシュサーバ、ロードバランサーで構成されています。
新システムの構築プロジェクトは無事に完了し、本番稼働の時を迎えました。サービスイン直後は快適に動いていましたが、その日の昼頃には速度低下が報告され始め、夕方ごろには無視できないレベルの苦情が上がるようになってしまいました。
そこであなたのチームは、原因究明を始めます。ロードバランサーへのトラフィックや、各種サーバのメトリクスをチェックしました。すると、アプリケーションサーバのCPU負荷が高くなっていることに気づきます。よくよく調べてみると、アプリケーションへのアクセスが想定したよりも多く、CPUを大きく消費していることが分かりました。新システムへのアクセスを行う社員が増えるにつれ、どんどん速度が低下していったものと思われます。遅いシステムに業を煮やした社員がリロードを繰り返すことが、さらに速度低下を引き起こしているかもしれません。
対応策として、あなたは2つの方法を考えました。一つは既存のアプリケーションサーバのCPU割り当てを増やす方法（スケールアップ）。もう一つは、アプリケーションサーバの台数を増やす方法（スケールアウト）。スケールアップは行える幅に上限がある一方、既存サーバの設定を変更するだけなので素早く対処を行うことができそうでした。スケールアウトは、台数を増やしていけば上限なく処理能力を向上させられる一方、追加するサーバの設定を行わなければいけないこと。またロードバランサーへの設定追加も必要と思われ、明日の朝までには間に合わないことが予想されました。
そこであなたはスケールアップの方法をとることを決断し、定時後のユーザーが減った時間を見計らって作業を行いました。その結果、新システムは安定を取り戻し、苦情が上がることもなくなりました。初日の問題は「システムの稼働初期にはよくある事象」とされ、1日で解消したことで不問に付されました。あなたはITマネジャーとしての責務を果たせたわけです。めでたしめでたし。
クラウド以前の「ITインフラあるある」的な想定事例として書いてみましたが、これを「めでたしめでたし」で終わらせてはいけません。なぜかというと、この話には、たくさんの人間や手作業が関与しているからです。
- 速度低下していることを、人間（ユーザー）が判断して報告している
- 速度低下の原因を調べるため、人間がリソースのメトリクスをチェックしている
- 取り得る選択肢を人間が考え、メリットデメリットを考慮して決断している
- 人があまり使っていない時間帯を見計らって作業している
- 人間がサーバリソースの変更作業を行っている
それぞれのフェーズには数十分から数時間を要してしまっています。人間が運用を行う従来ながらのITインフラ基準で考えると、スムーズな対処が行われた部類に入るかもしれません。しかし、クラウドネイティブの時代において、この所要時間はあまりにも長すぎます。
運用するシステムが数個であれば、これでも回るかもしれませんが、数百のシステムを並行運用していたらどうなるでしょうか。あっという間に手が回らなくなってしまうでしょう。
また、決断が人に委ねられているところにも危うさを感じます。今回の例ではスケールアップかスケールアウトかの決断をあなたが行っていますが、もしあなたが他の業務に追われており、素早く判断できなかったらどうなるでしょう。はやりの病気に感染してしまい、数日間の休みを余儀なくされていたらどうなるでしょう。また、1人のマネジャーが判断することは許されず、緊急会議を開いた上で対応方針を議論し、合議の上で判断するというケースもあります。そうなってしまうと、対処には数日を要していたかもしれませんね。
クラウドネイティブ思考に基づく対処法とは
それでは、今回の問題に対してどう対処していくべきかを考えてみましょう。繰り返しになりますが、クラウドネイティブ思考とは「コンピューターの力でコンピューターを動かす」「人間の関与をなくしていく」にはどうするかを考えることです。表現を変えると「人間中心の考え」ではなく「コンピューター中心の考え」をしなければいけないことになります。
先ほどの「スケールアップかスケールアウトか」の例で考えてみましょう。これらの選択肢には、以下のようなメリット、デメリットがありました。
スケールアップのメリット
- サーバを新規セットアップせず、設定変更だけで実現可能（翌日の業務開始までに間に合う）
スケールアップのデメリット
- スケールアップの幅には限界がある
スケールアウトのメリット
- サーバ台数を増やせば増やすほど処理能力を上げることができる
スケールアウトのデメリット
- 追加分のサーバを設定しなくてはいけない（翌日までに間に合わない可能性）
- 追加したサーバをロードバランサーに設定する必要がある
スケールアップの手法は、サーバ1台当たりに追加できるCPUの上限があるため、次回以降は利用できないかもしれません。将来的にはスケールアウトの手段をとったほうがよさそうですが、サービスイン直後からトラブルが長引くのは社内の他部門への心証が悪くなる恐れもあります。状況を考えると「明日の業務開始までに問題を解消できること」を最重要課題とした方が良さそうです。そのため、今回はスケールアップを行うこととしました。
これは、完全に人間中心の考え方です。「長引くと社内の心証が悪くなる」「将来同じことをするのは難しいけど、今回はやむなし」という判断を、コンピューターに行わせるのは困難です。しかし、これをもって「コンピューターは柔軟な判断ができないから人間が必要だ」と考えてはいけません。 クラウドネイティブ時代においては、「コンピューターに判断ができないような業務フローにしてしまっている人間が悪い」くらいに考えるべきです。
ではどうすべきかというと、判断基準をできる限りシンプルにしていくのです。『CPUの使用率が70%を超える時間が10分以上続く場合、サーバをスケールアウトする』『システムの○○処理に関するレスポンスが300ミリ秒を超える状態が5分以上続く場合、サーバをスケールアップする』といった具合に、計測可能な指標を用いて、具体的なアクションを決めるようにします。そうすると、コンピューターで判断しやすくなります。
クラウドネイティブ思考を生かすための追加要件
これを実現するためには、幾つかの追加要件があります。
- 各サーバのメトリクスやレスポンスタイムなどを収集し、判断に利用できるようになっていること
- サーバを追加するだけで利用可能になること。そのためにアプリケーションのインストールや設定作業があらかじめ行われている、もしくは起動後に自動で行われること
- アプリケーションがスケールアウト可能なアーキテクチャになっていること
- 「システムが稼働しており、利用ユーザーがいる」状態でも無停止で追加作業を行えること
- 追加されたサーバはネットワーク上で発見可能であり、直接、もしくはロードバランサーを経由して自動で利用可能になること
人間中心に運用を行っていた時代は必ずしも必要とされていなかったこのような要件が、コンピューター中心の運用に行っていくに当たって重要となってくるわけですね。「うちのアプリケーションは人がインストールと設定をしないといけないから、スケールアウトできない」と妥協してはいけません。そこを自動化できるよう設計段階から要件を入れておくことが大事ですし、既存の仕組みは労力を割いてもいいので改良を加えていくべきです。
また、説明の都合上スケールアウトが前提となっていますが、スケールアップがNGと言っているわけではありません。ワークロードごとにどちらが適しているかは異なるため、ここで善し悪しを語るつもりはありません。重要なのは、判断基準がシンプルであることと、コンピューターで処理可能であるということです。
「明日の朝までに対処できること」という、組織的・政治的な判断はどうするんだ？という意見もあるかもしれません。しかし考えていただきたいのは「その判断って必要なんでしたっけ？」というところです。
コンピューターの速度で運用が回るようにすれば、「明日の業務が始まるまで」という人間の基準ではなく「レスポンスが遅くなったら即座に対応」することができ、結果として前者の条件を満たすことができるでしょう。そもそも、人間がシステムの速度低下を実感するより前に手を打って、問題発生を未然に防ぐことすら可能になります。
皆さんが普段行っている業務を振り返ると、コンピューター中心に考えればそもそも不要な判断がたくさんあることに気づくはずです。改めて普段の業務を洗い出してみるのも、クラウドネイティブ思考を深めていくためには重要です。
ヒューマノイドよりも、FAのロボットを使う
FA（Factory Automation）で自動化された工場を見たことはあるでしょうか？ 自動車をはじめとした製造業の先端では、多くのプロセスがロボットによって自動化されており、信じられない速度で生産が行われていますよね。
ここで用いられているロボットは、腕だけがグイグイと動くようなものであり、われわれ日本人が大好きな、ロボットアニメに出てくる二足歩行で頭のついたカッコイイものではありません。なぜこのような形になっているかというと、「そのほうが効率がいいから」です。
人間の生活圏にそのままロボットを適用するのであれば、人間と同じように二足歩行ができて2本の腕と手があるロボット、すなわちヒューマノイドが欲しくなってきます。車輪では階段は上れませんし、手がなければ扉を開けることができません。
しかしFAの世界では、生産性が何よりも重要です。障害物がなければ二足歩行よりも車輪のほうがずっと効率的ですし、ネジ締めするのであれば足は不要です。さらには、2本の腕、5本指である必要もありません。そう、生産ラインを人間前提ではなくFA前提で組むのであれば、ヒューマノイドは非効率の塊なのです。生産性を高めるためには、階段を上れるヒューマノイドを用意するのではなく、そもそも階段をなくすというアプローチが重要になってきます。
ネジ締めするだけのロボットにアルミの削り出しをさせることはできませんが、それは特に問題にはなりません。ネジ締めはネジ締め、削り出しは削り出しに特化したロボットを用意すればいいからです。そして、そのロボット間をベルトコンベアーでつなげば、流れるように生産が進むわけです。10万馬力のヒューマノイドを数体用意するよりも、腕しかない特化型ロボットを投入した方が、ずっと速いし安く済むはずです。
ITにおいても目指すべきは同じ方向性です。クラウドネイティブ思考なしにITインフラ自動化を考えると、どうしてもヒューマノイド的なものを考えがちです。
例えば、人間の操作をそのまま代替するRPA（Robotic Process Automation）を安易に導入するべきではありません。非効率な人間中心のプロセスを、場当たり的な対処でごまかしてしまうことになりかねないからです。
まずはクラウドネイティブ思考で、コンピューター中心の設計と構築を行いましょう。その上で、どうしてもその時点では時間的・コスト的に変更が難しい部分に対して、一時的な対処としてRPAを適用するという形で行っていくべきです。
さて、次回からは、クラウドネイティブ技術と呼ばれるさまざまな新しい技術を用いて、どのような改善が図れるかを解説していきます。
特集：マネージャーこそ知りたい「クラウドネイティブ」大注目のワケ
人々とビジネスをつなげる「アプリケーション」は企業価値の源泉といっても過言ではない。ITを通じたビジネス提供が常識となる中で、 なぜ「クラウドネイティブ」は注目されているのか。本特集は“マネージャーこそ知りたい”と題し、クラウドネイティブの基本と本質に立ち返る。
Copyright © ITmedia, Inc. All Rights Reserved.