「Knative」とは何か【後編】

「Knative」のメリットを“帳消し”にしかねない注意点とは？

「Kubernetes」でイベント駆動型プログラミングを実装するために、「Knative」は良い選択肢になり得るが、注意すべき点も幾つかある。何に注意すべきなのか。

公開 2020年10月06日 05時02分

[TechTarget]

印刷する連載新着通知を受け取る

　サーバの存在を意識せずにアプリケーションを開発・運用できる「サーバレスアーキテクチャ」は、CPUやメモリなどのコンピューティングリソースの自動割り当てを可能にするなど、管理者にさまざまなメリットをもたらす。これを具現化する手段の一つに、特定のイベントをトリガーにしてプログラムを自動実行する「イベント駆動型プログラミング」がある。

　イベント駆動型プログラミングを実現する際の候補になるのが「Knative」だ。Knativeは、コンテナの運用管理を自動化するコンテナオーケストレーター「Kubernetes」でのイベント駆動型プログラミング実施を支援する。アプリケーション稼働時にイベント数が変動し、想定範囲内にコンピューティングリソースの利用が収まるアプリケーションは、Knativeが向いている。

　Knativeは、イベントを起点にしたプロセスの実行にも適する。具体的にはネットワークモニタリング、アプリケーションモニタリング、Webサイトのテスト・検証、モバイルアプリケーションのフロントエンドプロセス実行などだ。

Knativeを使う場合の注意点

　企業がKnativeを利用する際、まず気を付けるべき課題は効率性だ。適切なアプリケーションの組み合わせに対してKnativeを導入すれば、イベント駆動型プログラミングを採用したアプリケーションのパフォーマンスを向上できる可能性がある。ただしアプリケーションの組み合わせが不適切だった場合、コンテナを十分に活用できずにコストが上昇したり、コンピューティングリソースが不足してアプリケーションのパフォーマンスが低下したりする可能性が生じる。アプリケーションの間違いやリソース不足は、Knativeのメリットを帳消しにしかねない。

併せて読みたいお薦め記事

サーバレスアーキテクチャの実装方法

Kubernetes活用のヒント

　こうした課題を解決するには、アプリケーションの組み合わせとコンピューティングリソースの量を検証するためのテストをKnativeで実施する必要がある。イベント発生時にアプリケーションに掛かる負荷を測定し、それぞれのイベントについて最大負荷と平均負荷を測定するとよい。総リソース消費量を推定するために、予想されるイベントに基づいて、Knativeのプロセス実行にかかる時間を計測。これを複数のアプリケーションで実施し、推定値を検証する。導入は段階的に進め、実装やリソース構成、あるいはその両方を検証しながら調整するとよいだろう。

　Knativeの機能に関する課題は2方向に分かれる。第一に、Knativeは「ステートレス」のアプリケーションに適した機能を実現する。ステートレスとは、各セッション（通信の開始から終わりまでの接続単位）のためのデータをサーバに保持せず、処理に必要な全てのデータをリクエスト（サーバへの接続要求）に持たせることだ。そうした機能の開発は、アプローチを誤れば想定通りの性能を発揮できない恐れがある。第二に、アプリケーションが多段階のトランザクション（処理単位）で構成されるデータを取り扱う場合、ステートレスのアプリケーションではトランザクション間でデータを保持しなければならない。その機能はKnativeにはないため、管理者は自分でデータを管理する機能を実装する必要がある。

　イベント駆動型プログラミングのインフラとしてクラウドサービスと比較すると、Knativeには運用上の課題がある。クラウドサービスの場合、基盤となるサーバを自社で管理しなくてよい。Knativeを使う場合は、サーバだけでなくコンテナ、Kubernetes、コンテナ間の通信を制御する「サービスメッシュ」の「Istio」、Knativeそのものも管理しなければならない。

　既にコンテナやKubernetesを活用している企業の場合、Knative導入による開発と運用の複雑性増加は最小限にとどめられる。サービスメッシュを活用しているのであれば、Knativeは自然な機能の拡張になるだろう。