Kubernetesの自動スケーリング機能の落とし穴：失敗しないコンテナ化戦略【後編】

Kubernetesの自動スケーリング機能（オートスケーラー）を利用することで、クラスタのサイズを自動的に調整できる。だが、ここに落とし穴がある。

[Adrian Bridgwater、Cliff Saran，Computer Weekly] PC用表示関連情報

LINE

Hatena

　前編（コンテナ移行を阻む課題と解決のヒント）では、レガシーアプリケーションをコンテナ化する際に発生する課題と解決策を紹介した。

　後編では、コンテナ化したアプリケーションの運用時に発生する可能性のある問題と、迅速なコンテナ化を成功させる3つのステップを紹介する。

管理の考慮事項

　コンテナは、レガシーアプリケーションのモダナイズだけでなくソフトウェア開発のパイプラインを再検討する機会を提供する。

　実装を管理するためにコンテナやKubernetesを採用する企業がますます増えている。そう話すのはオープンソースデータベース企業Perconaのセルゲイ・プロニン氏だ。

　「コンテナはソフトウェア開発パイプラインの中で優れた働きをし、デリバリーを容易にする。コンテナ化したアプリケーションはいずれ運用環境に移動し、管理はKubernetesが担う。誰にとっても素晴らしいことだ」と同氏は述べる。

　Kubernetesのおかげでプロセッサ、メモリ、ネットワーク、ストレージの各要件が動的に処理され、アプリケーションは使用量のピークに対応するスケールアウトやスケールダウンをプログラムで実施できるようになると同氏は補足する。

　ソフトウェアエンジニアリングチームは、Kubernetesにオートスケーラーを設定してアプリケーションの可用性と回復力を高めている。だが、これではクラウドの請求額が急速に膨れ上がる恐れがあるとプロニン氏は警告する。

　例えば「Amazon EBS」（Elastic Block Store）ユーザーは、実際には1TBしか利用していなくてもプロビジョニングされる10TBの料金を支払うことになる。「コンテナは利用開始時の要件でリソースを確保するため、必要になる可能性のある量を多く見積もり過ぎると請求額が大幅に増えるかもしれない」とプロニン氏は話す。

　コンテナに移行するワークロードが増えるにつれ、最終的にはコンテナの複数のクラスタを管理することになる。全体像を把握するため、コンテナの使用量や費用レベルを追跡することがIT部門にとって重要になる。

コンテナ化を成功に導く3つのステップ

　コンテナ化を迅速に成功させることを優先して長期戦略を策定するには、コンテナ化のプロセスを管理可能な複数の段階に分割し、それらを複雑さの順に並べ替えることだ。そう話すのは、Persistent Systemsのジアニ・チャン氏（アライアンスおよび産業ビジネス部門役員）だ。同氏は、コンテナ化を目指すIT意思決定者に次の3つのステップの検討を提案する。

リホスティング（ホスト先の変更）

　できる限り早く成功を収めるのであれば、この最もシンプルなコンテナ化手法に着目する。ホスト先の変更はリフト＆シフトとも呼ばれる。これがレガシーアプリケーションをコンテナ化してクラウドに移行する最も容易な方法だ。

　ホスト先の変更によって、ROI（投資収益率）を短期間で劇的に高めることが可能だ。全アプリケーションのホスト先を変更できるわけではない。だが、早期に着手すれば複雑なタスクに時間をかけながら、より長くメリットを享受できる。

リファクタリング

　リファクタリングはホスト先の変更よりも時間がかかる。レガシーアプリケーションをコンテナ化してマイクロサービスに分離することで、コード全体をリファクタリングすることなくアプリケーションの最も重要な部分を移行するというメリットが得られる。時間と作業量という点では、アプリケーション全体ではなく、最も重要なコンポーネントのみを移行することが理にかなっていることは多い。

　この実用的な例の一つがレガシーアプリケーションのストレージメカニズム（ログやユーザーファイルなど）のリファクタリングだ。これにより、データを失うこともなく全てをコンテナに移行することもなく、コンテナ内でアプリケーションを実行できる。

リビルド（再構築）

　損失を減らすために、有効性が低下したアプリケーションを再構築しなければならない場合がある。これには時間がかかる。だがこうしたアプリケーションは、システム内で最もコストがかかるが生産性は低くなっている場合が多い。そのため再構築によって長期的にはメリットを得られる可能性がある。