松本 龍幸
日本アイ・ビー・エム株式会社
IBMコンサルティング事業本部
プリンシパル・アーキテクト
クラウド・アドバイザリー
ライブ・イノベーション担当
「パフォーマンスの罠」とは？
モダナイゼーションにおける代表的な取り組みの1つに、適切なアプリケーション分割による、保守時の柔軟性や迅速性の向上があります。
従来の基幹システムの多くでは、1つのシステム内でほとんどの業務処理が完了する構造でしたが、マイクロサービス化によるモダナイゼーションでは、アプリケーション分割により、分散処理が発生します。分散処理以外にも、アプリケーションの柔軟性向上のために変化へ備えた抽象層を追加することで、処理の冗長性が増加します。これらにより、アプリケーションの処理負荷は増加していく傾向があり、パフォーマンス問題が顕在化することがあります。
アプリケーションを大きく変更しない場合でも、稼働基盤変更によるパフォーマンス・リスクがあります。最近ではコンテナ・ファーストというキーワードも広まりつつあり、運用自動化や、コンテナ不変性によるリリース一貫性の確保などを目的に、コンテナへのモダナイゼーションを進めている企業も増えてきました。アプリケーション運用に様々な効果をもたらすコンテナですが、パフォーマンス面、特に大量のファイルI/Oには注意が必要です。コンテナ以外でも、オンプレミス（以下、オンプレ）からクラウドへの移行によるネットワーク経路変更の影響、アプリケーション起動特性によるレスポンス影響など、単純移行（リフト）においても油断はできません。
このようなアプリケーション構造や稼働基盤の変更に起因するパフォーマンス劣化リスクを「パフォーマンスの罠」と呼び、適切なリスク評価によりこの影響を検証しておく必要があります。
実際に起こっている問題
それでは、実際にどのようなパフォーマンスの問題が起きているのでしょうか。まずは『アプリケーション分割に起因するパフォーマンス・リスクの顕在化事例』からご紹介していきます。
- 分散連携への変更による性能劣化
マイクロサービスに代表されるアプリケーション分割では、デプロイ単位の明確な分割のために、REST APIでのHTTP連携や、MQ/Kafkaなどのメッセージング連携による分散処理連携を採用しています。分散連携による処理のオーバーヘッドは無視できず、注意が必要です。 - 分散トランザクションへのアプリケーション対応に起因する処理増加による性能劣化
上記1に加え、HTTPやメッセージングによる分散連携では、二層コミットのような一括のトランザクション制御機能が提供されておらず、一連の連携処理の途中で障害が発生した際には簡単に一括ロールバック処理ができず、独自の障害対応実装が必要となります。マイクロサービスでは結果整合性の考え方で、トランザクション整合性を担保する方針に沿ったいくつかのデザイン・パターンを提唱していますが、その実装によりアプリケーションは複雑・冗長になり、オーバーヘッドが増加します。
- データ・アクセス分割によるSQL発行数の増加による性能劣化
アプリケーション分割によるSQL発行数の増加傾向もリスクとなります。アプリケーション分割では、アプリケーションに従属する形でデータも分割することが推奨されていますが、この際に、これまで1つのSQL内でのテーブル結合によって実現できていたデータ・アクセス処理が分割され、複数のSQL発行が必要となるケースがあります。
- コンテナからの永続ストレージへのアクセスによる性能劣化
コンテナでは、永続的または他コンテナやシステムと共有するストレージが必要であれば、外部のストレージをマウントする必要があります。基本的に永続的ストレージへのI/Oはオーバーヘッドが大きく、メインフレームの高速I/Oを前提とした大量のファイル・データを扱うバッチ処理のリフトではスループット要件を満たさずに、バッチ・ウィンドウ内に処理が収まらない致命的結果となるケースがあります。
- ネットワーク経路変更による性能劣化
オンプレからクラウドへアプリケーションを移行する事で、オンプレ・ユーザーからのアクセスにおいてネットワーク遅延（レイテンシー）が悪化します。単純なPCとクラウドのネットワーク遅延以外に、システム間連携へのネットワーク影響や、初期データベース構築時の移行データ転送への影響に関してもリスクとなります。
次に『稼働基盤変更によるパフォーマンス・リスクの顕在化事例』をご紹介します。
「パフォーマンスの罠」の乗り越え方
これらのリスクを乗り越え、無事モダナイゼーションを実現するためにはどのような対応が必要でしょうか。
- 分散連携への変更による性能劣化
一度の処理での連携数の目安を設け、あまり細い分割を避けます。1つの処理内で10以上の分散連携があれば粒度を見直すべきです。また1件単位の処理APIに加え、複数件一括の処理APIを提供することで連携数を削減できます。
- 分散トランザクションへのアプリケーション対応に起因する処理増加による性能劣化
まず1と同様に、トランザクション単位を考慮したシステム分割を検討しますが、業務要件により分散トランザクションが必須要件となるため、効率的な結果整合性確保の仕組みが必要となります。TCCパターン※1やSagaパターン※1といった方式が有名ですが、APIの冪等性を担保した設計による、単純リトライによる対応実現がシンプルです。
- データ・アクセス分割によるSQL発行数の増加による性能劣化
CQRS※2のような更新系と参照系で別モデルを利用するパターンによる改善を検討します。データ・レプリケーションを伴う実装が多く、データ鮮度の考慮が必要です。
- コンテナからの永続ストレージへのアクセスによる性能劣化
大量ファイル処理を伴うバッチのコンテナ・リフトでは、早期に実装検証を実施し、性能面の妥当性を評価します。SSD化などストレージ側での改善対応が困難な場合、処理方式の修正が必要です。ファイルのDB化や、仮想ファイル上で処理した後に一括でストレージに転送するといった処理方式を検討します。後者は障害時にリラン（再実行）する際、途中からのチェックポイント・リスタートが困難であり、バッチ・ウィンドウ要件上の評価が必要です。
- ネットワーク経路変更による性能劣化
ユーザーの期待値管理が必要となります。また専用線の帯域拡大によるレイテンシー向上には限界があり、並列連携処理や、複数連携呼出の一括化など、連携方式の見直しによる改善を検討します。移行データのクラウドへの取り込みに関しては、高速転送ツールや物理ストレージでの持ち込みなどをクラウド側で提供している場合があり、これらの利用を検討します。
まとめ
今回は、モダナイゼーションにおける「パフォーマンスの罠」をテーマに課題や対応方法をご紹介しました。コンテナからの永続ストレージI/Oなどは今後の技術改善により解決されることを期待しています。
本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もご覧ください。
参考文献
※1 IBM Cloudのマネージド・サービスで実現するマイクロサービス・アプリケーション「2.トランザクション管理の方法」
※2 Command Query Responsibility Segregation（CQRS）（英語）
