[まとめ記事] 驚異的なKubernetesの光と影
最新IT技術の目玉であるKubernetesのソースコード勉強会(第6解)を2021年3月3日に聴講しました。
マジンガーZというロボット・アニメでは、「神にも悪魔にもなれる」というキャッチフレーズがありました。まさにそのような潜在能力を秘めているがKubernetesだと分かりました。
みずほ銀行や東証のような重要なシステムを、素人が簡単に構築することが可能なのです。レゴブロックのように組み立て操作をするだけで、必要な作業の大半が終わってしまいます。
しかしその一方で、思わぬところに地雷が潜んでいます。高度で複雑なシステムを簡単に見せている分、危険な部分まで隠れて見えなくなっています。
今回はKubernetes利用が簡単に見える様子と、関係者の課題、そして素人には危険な部分を紹介させて頂くことにします。
Kubernetesの簡単さ
Kubernetesを使ってコンピュータシステムを構築するのは、恐ろしく簡単です。特に最近ではクラウド上にはKubernetesサービスや、Kubernetes搭載HCIアプライアンスが存在します。
事前に必要となる部材の見積もり(サイジング含む)や、ハードウェアを設置してケーブル接続してOSやプログラムをインストールして … こういった厄介ごとは不要です。1年以上を必要としていた時間が、一気に “ゼロ” になります。
そして冒頭画像に表示されているような文字列が、Kubernetesのソースコードです。マイクロサービス化されて関数形式で呼び出すだけで良いのです。
フローチャート不要
昔はシステムの基本構造を設計した後、フローチャートという流れ作業図を描いて、それをソースコード形式に書き込んでいました。一部のクセが強い凄腕開発者たちが書いたカウボーイ・コードなどと呼ばれるものは、フローチャート図が無いと理解できない代物でした。
(いやいやフローチャート図を書いても理解は難しく、Python言語の開発プロジェクトではカウボーイコード禁止令が発令されている程です)
それが今では関数の集合体のような形式に纏められて、レゴブロックを組み上げるようにプログラム開発できるのです。従来は数年がかりだったシステム構築作業も、数週間で終わらせることが可能です。
サービス尋ねて三千行
さて数年がかりの作業が数週間で済むようになると説明しましたけれども、その肝が先程の関数(API)形式の活用です。
見出しの「サービス尋ねて三千行」は、Kubernetes Internal(ソースコードレビューによる内部構造の勉強会) 第6回のYoutube動画ラスト部分です。
今までの感覚では、プログラムを書くというと三万行くらいが一般的です。それが1/10の三千行に減っている訳です。構造が簡略化するということは、基礎設計も楽になることに繋がります。だから開発期間を数週間に縮めることが可能です。
関数に任せるというのは、既に標準品として開発された処理(サービス)を使うということです。これが構造を簡略化するカラクリです。
だから三千行のソースコードの中に含まれる関数を辿る … その処理内容をを尋ねる(確認する)ということになるのです。
そして頭を絞って三千行に押し込むのではなく、単純なサービス利用によって三千行で済むということは、余裕が生じるということです。今まで百人体制でソースコードを実装していたとしたら、その人数を1/10程度に減らすことが可能になります。
子供の頃に観たアニメでは、「モビルスーツの性能差が戦力の圧倒的差にはならん」というセリフがありましたけど、Kubernetesを利用してマイクロサービス化をすることによって、戦力の圧倒的な差が生じてしまう訳です。
関係者の悩み事
さてそんな素晴らしいKubernetesですけれども、利用者にとって大きな懸案事項が存在します。それが「ネットワーク通信処理」です。
マイクロサービスでは1プロセス1DBの原則があるため、データ管理は大きな課題ではありません。身近なところでは、メルカリという逆オークションサイトがKubernetesによるマイクロサービスを採用しています。
しかしメルカリはWebサーバをフロントに立てて、データセンタ内で集中的に処理する典型的な三階層型クライアント/サーバシステムです。このような既存型ITシステムは、Kubernetesのようなマイクロサービスでなければ扱えない分散システムではありません。
その分散システムを実現するには、物理サーバ間で通信処理が発生する訳です。おまけに簡単だといったものの、既存ITシステムにしてもマイクロサービスの集合体です。サービス間の通信処理が必要となります。
それでKubernnetes Internal #6というソースコード・レビュー会でさえ、「乞う！ ネットワークの専門家！」というボヤきが出て来た訳です。昔も今も、ネットワーク屋さんは「縁の下の力持ち」として重要な存在です。
(某社のワークステーション設計部隊にしても、OS部門、ネットワーク通信部門、アプリケーション部門と3つに分かれていました)
このネットワーク通信処理部分が、現時点でKubernetes関係者にとって大きな懸案事項となっています。そしてこれを軽減するため、スタートアップがGPUだとかFPGA処理機能(VMware NSX/vSAN等)付きNICカード製品化を検討している訳です。
素人に危険な部分
さて私のような市民ITエンジニアでさえシステム構築できてしまうKubernetesは、実は素人には大変に危険な存在です。
何しろAI(Deep Learning)の学習システムを構築するような作業と違って、「安定稼働」が重要となります。万一でもメルカリがサービス停止してしまったら、みずほ銀行や東証のようにニュース報道されてしまうかもしれません。
実は先ほどのように、日本のトップ技術者たちでさえ音を上げる部分(ネットワーク等)が存在します。実は高度で複雑な処理が、関数(サービス)として全て隠されているのです。
だからKubernetesはおろか、ITシステムやコンピュータシステムに詳しくない私のような者でさえ、Kubernetesを使ってお客様向けWebサービスを開発することが出来ます。
実際、私はWordPressというlo-code/no-code型Webアプリケーションプログラムを使って、独自ドメインのブログサイトを運営しています。Kubernetesも、基本的な作業内容は変わりません。
WordPressとKubernetesで大きく異なるのは、Kubernetesはサービスを組み合わせて利用することです。だからネットワーク部分は単純に頭が良いとかプログラミング技術が高いだけでなく、ネットワーク方面の専門知識も必要となる訳です。
(ネットワーク方面の専門家だったら、「あ、これ、xxxをyyyすればオッケー」レベルで済む可能性が高いとのことです)
だからテキストや市販本で紹介されている内容をそのまま完コピ(丸写し)する程度ならば簡単だけれども、素人が本格的なシステムを構築するのは無理があります。
- エンドユーザからの処理要求を実行可能
- 安定稼働してサービス全体は停止しない
- メンテナンスや回収が簡単
特定のサービスが困っても、それが冗長化されていたりして、別なサービスで処理できてしまえば問題ありません。人間の体のようなもので、「具合が悪いところがあっても、それを補いながらシステムとして動ければオッケー」という訳です。
こういうシステムを構築するためには、プログラミング技術とKubernetes内部構造(動作仕様)への理解が大切となって来ます。だから私が今回参加したようなKubernetesソースコードの勉強会が開催されている訳です。
(決してカウボーイ的な腕自慢の技術者が自己PRとか暇つぶしのためにKubernetes Internalを開催しているのでは無いのです)
まとめ
以上の通りで、Kubernetesシステムは簡単に使いこなせるように見えますけど、一流の技術者たちからしてもネットワーク部分など厄介な部分が存在しており、素人が迂闊に手を出して大惨事となる可能性のあるマイクロサービスです。
便利だけれども、十分にスキルを身に付けた上で取り組むことがオススメとなります。使いこなせるようになれば、本当に素晴らしいシステムを構築・運用できるようになります。
ただし「悪貨が良貨を駆逐する」というのが世間一般的な原則です。Kubernetesは素晴らしい存在ですけれども、果たしてどこまで普及するかは微妙であるような気がしています。(完全に私の私見)
それでは今回は、この辺で。ではまた。
———————-
記事作成：小野谷静
