データ更新を伴うAIシステムの運用をKubernetesで簡単に実現する方法

このエントリーをはてなブックマークに追加

こんにちは、データデザイン部の尾崎です。
普段はデータエンジニアとして、AI系アプリケーションにおけるシステム構築を行っています。

一般的に、業務データは日々更新されるものがほとんどです。そのようなデータを用いてAI開発を行う場合、データが更新されるに伴って、機械学習モデルを作成し直す必要があります。加えて、機械学習モデルが更新される度に、それらをアプリケーションに適用するためのメンテナンスも必要となります。

しかし、メンテナンスの度にシステムを停止させることは、ビジネスの観点から許容できないケースが多いと思います。

そのような、定期的なデータの更新を伴いつつも、停めることができないAIアプリケーションにおいては、システム設計が重要となります。

直近、私も上記のような要件の案件を担当いたしました。その際、要件を満たす技術や基盤を選定するための検証と検討を行いましたが、最終的にKubernetesを活用したクラウド基盤を採用しました。

そこで、本稿ではデータ更新を伴うAIアプリケーション運用における、Kubernetesの有用性について解説します。

目次

  • Kubernetes基盤を利用するメリット
  • ローリングアップデートを用いたアプリケーションの無停止メンテナンス
  • readinessProbeの設定

Kubernetes基盤を利用するメリット

Kubernetesとはコンテナのオーケストレーションツールであり、複数のコンテナを利用するシステムの開発と運用をより簡単に実現するためのツールです。

昨今、Dockerを導入してコンテナを利用しているケースは多いと思いますが、コンテナ間のネットワーク設計や監視設計には少し手間がかかります。このような課題をKubernetesを導入することによって、簡単に解決することが可能となります。

Kubernetesには様々な機能が実装されていますが、定期更新が発生するAIアプリケーションのメンテナンスにおいては、ローリングアップデート機能が有用となります。

ローリングアップデートを用いたアプリケーションの無停止メンテナンス

Kubernetesのローリングアップデート機能を利用することによって、アプリケーションを停止させることなく、更新メンテナンスを行うことが可能です。

具体的に、ローリングアップデートが実行される手順を示します。今回は、ロードバランサー配下に2つのアプリケーションコンテナが実行されてる状態を前提とします。

① 通常時
ロードバランサー1台、アプリケーションコンテナが2つ存在している状態です。このアプリケーションに対して、ローリングアップデートを実行します。

② コンテナAの終了
ローリングアップデートが実行されると、コンテナAが終了します。

③ 新コンテナの起動と新コンテナA’の接続
コンテナAの終了後、新しいコンテナA’とB’が作成されます。新コンテナA’がロードバランサーに接続されます。

④ コンテナBの終了
新コンテナA’との接続完了後、コンテナBが終了します。

⑤ 新コンテナB’の接続
コンテナBの終了後、新コンテナB’がロードバランサーに接続されます。

⑥ ローリングアップデート完了
コンテナが2つとも更新されて、ローリングアップデートが終了となります。

図から分かる通り、上記の工程において、ロードバランサー配下には常にいずれかのコンテナが接続されている状態となっているため、常に外部からのアクセスに対して応答可能な状態が確保されています。そのため、アプリケーションを停止することなくメンテナンスを行うことができるのです。

readinessProbeの設定

ローリングアップデートによる無停止メンテナンスを行う際には、コンテナの挙動に応じてreadinessProbeも合わせて設定する必要があります。その理由を以下に説明します。

利用する機械学習モデルが定期的に更新されるAIアプリケーションにおいては、以下のようなコンテナの設計になっているケースがあるかと思います。

ローリングアップデートを行う際、readinessProbeを設定していないと、コンテナが起動したばかりの時点(①)でロードバランサーと接続されてしまいます。しかし、その時点では、まだアプリケーションの起動(③)まで間に合っていないため、外部からのアクセスを受けたとしても応答ができません。

この課題は、readinessProbeを設定することによって解決が可能です。readinessProbeはコンテナがリクエストを受け付けることが可能か継続的に監視し、受け付けることができない状態の際には、通信の振り分け先から該当のコンテナを除外する機能です。

readinessProbeを設定しておくことによって、①の時点ではなく、アクセスを受け付けられる状態となった時点(つまり③の時点)で、初めてロードバランサーと接続されます。

readinessProbeの設定方法は、deploymentのymlファイル内に設定を記載するのみです。以下に例を記載します。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: machine-learning-app
  labels:
    app: machine-learning-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: machine-learning-app
  template:
    metadata:
      labels:
        app: machine-learning-app
        tier: frontend
    spec:
      containers:
      - name: machine-learning-app
        image: machine-learning-app
        imagePullPolicy: Always
        ports:
        - name: http-server
          containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: http-server

最後に

今回は、データ更新を伴うAIアプリケーションにおける、Kubernetesの有用性について記載しました。

このように、AIアプリケーション構築には、機械学習モデルの作成だけではなく、周辺のシステム開発も必要となります。弊社では、システム構築も含めたAIアプリケーション構築のご支援が可能ですので、是非ご相談ください。

データサイエンスに関するブログ記事まとめ

富士通クラウドテクノロジーズのデータデザイン事業で働くデータエンジニアやデータサイエンティストがブログでデータ活用やAIに関する技術記事を公開しています。

過去の記事はこちらからご覧いただけます。

データサイエンス関連記事はこちら

WRITER
Kenta Ozaki

データエンジニア

尾崎 健太Kenta Ozaki

不動産やメディア系の案件にて、AIアプリケーションにおけるシステム構築やデータ整形を担当。 JDLA Deep Learning for GENRAL 2019#2

最新記事

ページTOPへ