連載
» 2018年12月20日 05時00分 公開

KubeCon + CloudNativeCon 2018詳報(3):2000店舗に展開の事例など、エッジでのKubernetesに注目が集まる

全米2000店舗にKubernetesクラスタを展開しているファストフードチェーンの事例などで、エッジにおけるKubernetesへの関心が高まっている。Kubernetesコミュニティーでも議論が始まった。

[三木泉,@IT]

 Kubernetes関連の最近の話題の一つに、米ファストフードチェーンのエッジコンピューティング事例がある。

 これは「Chick-fil-A(チックフィレイ)」というチキンサンドイッチチェーン。全米約2000の店舗にKubernetesを導入している。

 目的は、的確な需要予測により、働く人たちの生産性を高めて事業をスケールすることだと、「Chick-fil-A Tech Blog」のブログポストは説明する。各店舗の売り上げは、周辺の天候や各種イベントに大きく左右されるため、全店共通の予測では十分でない。各店舗のPOSやチキンフライヤーからのリアルタイムデータで予測を補完することにより、はるかに的確な予測ができるとする。これにより、店舗でチキンを揚げる作業者が、今毎分どれだけの数のチキンを揚げるべきかを示したり、将来の調理自動化につなげたりできるという。

 そこで、各店舗にKubernetesを活用した機動的なエッジコンピューティング/IoTの仕組みを導入。データを収集し、フィルターした上でクラウドに送ると共に、クラウドで行った予測とローカルのデータを組み合わせてその店舗のための判断を行うプロセスを動かしているという。

これだけの数の店舗が、それぞれ「マイクロデータセンター」になっている(Chick-fill-Aブログポストより)

 ブログポストはユーモアを込めて、「私たちは世界最大のクラウド事業者だろうか? あなたが判断してほしい」と述べ、「真剣な話、私たちの方法ではユニークな形でスケールが得られている。数十万のコンテナが走るK8s(Kubernetes)クラスタに代えて、各クラスタで数十のコンテナが走るクラスタを2000以上持つことになる。さらにその数は、毎年多数のレストランがオープンすることで大幅に伸びていく」と続けている。

 Chick-Fill-Aは各店舗で3台のコンピュータによるベアメタルKubernetesクラスタを構成し、その上でコンテナアプリケーションを動かしている。アプリケーションをコンテナで動かす理由は、依存性管理が容易で、開発作業も楽であり、CPUやメインメモリの制限がある中でも迅速な対応ができるからだという。

Chick-fill-Aが直面した課題とは

 上記のようなエッジコンピューティング/IoTにおけるKubernetes利用が進むにつれ、幾つかの課題が浮かび上がってくる。

 例えば前述のChick-Fill-Aでは、各店舗でKubernetesクラスタを導入する作業に工夫が必要だったと、別のブログポストが説明している。

 それぞれの店舗で小型サーバ群を導入するのは専門家ではない。電源を入れ、ネットワークケーブルを接続し、起動プロセスを確認することしかできない。こうした状況で、複数コンピュータによるKubernetesクラスタを自動的に構成する適切なツールが見つからなかった。そこで「Highlander」と呼ぶクラスタ初期構成ツールを作ったという。

 このツールでは、各ノード(コンピュータ)が起動すると、UDPによるブロードキャストで、自身が起動したことを広告すると共に、既に立ち上がっているノードがあるかを確認する。起動しているノードがなければ、数秒後に自身がクラスタのリーダーになることを広告する。反対がなければ、クラスタリーダーとして自らを確立するようになっている。

エッジでのKubernetesを議論するワーキンググループが発足

 KubernetesプロジェクトではIoT Edgeワーキンググループを設置。IoTおよびエッジコンピューティングでのKubernetes利用に関わる課題を議論していくという。

 ワーキンググループメンバーの説明によると、エッジでKubernetesを動かす際には、リモートでのライフサイクル管理が求められる一方で、ネットワーク接続が途絶えた場合の自己完結的な稼働を確保する必要がある。また、コンピューティング、ストレージ、ネットワークと全てのリソースが制約を受ける。例えばコンピューティングについてはオートスケールができないことを想定すると、ワークロードの優先度を考慮した稼働管理が必要だという。また、ストレージ容量も限定されているため、新たなデータ管理手法が求められる可能性がある。ネットワークについても、アップロード帯域が狭い場合を考え、優先度付けなどが必要になる。

 IoT Edgeワーキンググループでは、Kubernetesの既存機能で足りないものを特定し、こうした機能を補うことを議論していくという。既にメンバーのHuaweiは、KubeEdgeというツールをOSS化し、同ワーキンググループに持ち込んでいる。ただしKubeEdgeはTCPプロトコルに改変を加えるなど、Kubernetesコミュニティーで議論すべき範囲を逸脱しているのではないかと思われる部分もある。

 関連ベンダーの動きとしては、例えばRed Hatが今回のイベントで、開発中のOpenShift 4.0において、物理サーバ(ベアメタル)における導入・稼働管理の自動化に力を入れると説明した。想定しているユースケースは、パフォーマンスを要求される処理とエッジコンピューティングだ。

OpenShiftでは、エッジを含めた多様なクラスタ上のワークロードを統合管理する仕組みを構築している

 その上で、OpenShiftではオンプレミス、多様なクラウド、ベアメタルインフラに展開されるクラスタを統合的に管理する、「OpenShift Federated Control Plane」を提供するという。この機能により、コンテナアプリケーションを、それぞれに最適なクラスタへ直接デプロイできると共に、必要に応じて各アプリケーションを他のクラスタへ容易に移動できるようになるという。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。