「Akri」はMicrosoftが立ち上げた新しいオープンソースプロジェクトだ。Akriは、センサー、コントローラー、マイクロコントローラーユニット（MCU）クラスのような「リーフデバイス」を「Kubernetes」クラスタで接続する。
リーフデバイス（子デバイスと呼ばれることもある）とは、ダウンストリーム機器を持たないIoT（モノのインターネット）エッジ機器を指す。ダウンストリーム機器とは、他の全ての機器と同様、IoTハブでIDを必要とする機器を指す。
関連記事
- クラウドファーストの終焉――クラウドへの集約とエッジへの分散
- スタバとMicrosoftが構築したエッジコンピューティングシステム
- エッジコンピューティングシステムを自社開発してはならない
- IoT対応を進める英気象庁がMicrosoft Azureを選んだ理由
- エッジコンピューティングに伴うパラダイムシフト
Akriにおけるリーフデバイスとは、Kubernetesクラスタが通信できる全ての機器を指す。その機器がノードに物理的に接続されているかどうか、ネットワーク上で検出可能かどうかは問わない。例えば、Akriはデータを生成するだけでダウンストリーム機器を持たない機器や多くの機器のデータを集約するサーバも検出する。クラスタと通信できる機器はリーフデバイスとして抽象化できる。
ほとんどのエッジ機器は、Kubernetesを実行するには小さ過ぎる。AkriはKubernetesのデバイスプラグインフレームワークを拡張し、このフレームワークをエッジに適用することで機能する。
このプロジェクトにギリシャのエラッソナ市北部にある村の名前を付けた背景には、Akriがギリシャ語（άκρη）で「エッジ」を意味することもあるに違いない。Microsoftは、（エッジ向けの）「A Kubernetes Resource Interface」の頭字語「AKRI」だとも示唆している。
AkriはKubernetesネイティブ
Akriは、
- 2つのCRD（Custom Resource Definition）
- デバイスプラグイン実装
- カスタムコントローラー
という4つのKubernetesコンポーネントで構成される。
Akriはリーフデバイスの動的な出現と消失を処理する。ユーザーが「Akri Configuration」をクラスタに適用してデプロイすると、残りはAkriが処理する。複数のノードが1つのリーフデバイスを利用できるようにすることも可能だ。これにより、ノードがオフラインになった場合の高可用性を実現する。
Microsoftでオープンソースのエンジニアを務めるケイト・ゴールデンリング氏によると、エッジの特徴の一つはデータを生み出し、アクションを実行する多数のセンサー、コントローラー、MCUクラスの機器にあるという。
「Kubernetesが多様なエッジコンピューティングソリューションに対応するには、クラスタがこのようなリーフデバイスを簡単に見つける必要がある。ただし、こうした機器の大半はKubernetesを実行するには小さ過ぎる。では、Kubernetesのワークロードはこうしたリーフデバイスをどのように利用するのだろう。Kubernetesポッドはリーフデバイスの出力をどのように見つけ、アクセスするのだろう。その答えがAkriだ」（ゴールデンリング氏）
CNI（Container Network Interface）と同様、Akriは抽象化層を提供する。だが、基盤となるネットワークの詳細を抽象化するCNIとは異なり、Akriはカメラやセンサーなどのリーフデバイスの可用性を検出、利用、監視する作業を取り除く。
ゴールデンリング氏は続けて、Akriはデバイスプラグインフレームワークを利用し、これを拡張すると話す。このフレームワークは本来、GPUなどのリソース情報を定期的に送信するために作成されたものだ。
「Akriはこのフレームワークをエッジに適用する。エッジには独自の通信プロトコルと断続的な可用性を備えるリーフデバイスの多様なセットが存在する。Akriはリーフデバイスにアクセスするノードを継続的に検出し、ノードのワークロードのスケジュールを設定する。端的に言えば、ユーザーがリーフデバイスに名前を付け、Akriがそのリーフノードを見つけ出し、ユーザーがそのリーフノードを使用する」とゴールデンリング氏はMicrosoftの開発者向けオープンソースブログに記載している。
Copyright © ITmedia, Inc. All Rights Reserved.