re:Invent 2024: InforのCBSをAWSに移行、パフォーマンス48%向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Migrate and modernize a Microsoft-based banking solution with AWS (XNT313)
この動画では、InforのComplete Billing System（CBS）をAWSクラウドへ移行した事例が紹介されています。SQL ServerやWindows、.NETで構築されたCBSのパフォーマンス最適化において、コード変更なしで処理時間を33%削減するという目標に対し、4回のテストを重ねた結果、48%の削減を達成しました。EC2インスタンスタイプの選定やEBSボリュームの構成、IOPSの最適化など、具体的な改善プロセスが示され、最終的にSQL Server Standard Editionへの移行によってライセンスコストを74%削減し、総保有コストを24%削減することにも成功しています。100時間未満という短期間で、数千ドル程度のインフラコストで実現できた点も特筆すべき成果です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
InforのPricingおよびBillingソリューション移行プロジェクトの概要
本日はご参加いただき、ありがとうございます。InforのPricingおよびBillingソリューションの移行と最適化についての私たちの取り組みをご紹介できることを大変嬉しく思います。オンプレミスからAWSクラウドへの移行において、私たちが直面した課題や意思決定プロセスについてお話しさせていただきます。
私はFinancial Servicesのお客様をサポートするAWSのSenior Solutions ArchitectのBrandon Blincoeです。本日は、Microsoft Specialist Solutions ArchitectのAmirebrahim Sotoodehと、InforのCloud ArchitectであるBrad Schaufと共に登壇させていただきます。この事例を皆様と共有できる機会を得られたことを大変光栄に思います。これもInforとAWSの多くの仲間たちのサポートがあってこそ実現できました。本セッションでは、私たちの意思決定プロセスと移行の進め方について詳しくご説明します。また、このアプリケーションに必要とされるパフォーマンス要件を満たすために行った最適化についてもお話しします。これらのステップは多くのMicrosoftアプリケーションに応用できるものですので、皆様の次回の移行や最適化プロジェクトにおいて、一つでも多くの学びを持ち帰っていただければと思います。
Complete Billing System（CBS）の特徴と銀行業界のクラウド化ニーズ
InforのPricingおよびBillingソリューションはComplete Billing System（CBS）として知られており、主にMicrosoftスタックをベースとしたバッチ処理アプリケーションです。 このソリューションの多くのコンポーネントはC#と.NET Frameworkで構築されています。 また、SQL ServerやWindowsマシンも含まれています。 ID管理と認証にはMicrosoft Active Directoryを使用し、独自のSecurity Token Serviceも備えています。お気づきかと思いますが、これはFinancial Services業界におけるMicrosoftアプリケーションとしては非常に一般的な構成です。ちょっとお聞きしたいのですが、Financial Services企業にお勤めの方は手を挙げていただけますか？素晴らしいですね。では、Microsoftアプリケーションの移行をご検討中の方は？完璧です。では、皆様にはよくご理解いただけるはずですね。
クラウド導入以前のCBSは、永続ライセンスのセルフホスティングモデルを採用していました。銀行はInforからCBSを購入し、自社のデータセンターにソフトウェアをインストールする責任を負っていました。つまり、銀行はデータセンターでのアプリケーションのライフサイクル全体を通じて、パッチ適用、コンプライアンスやセキュリティの維持、需要増加に応じたスケーリングなど、すべての管理を担当する必要がありました。
最近では、銀行はビジネス戦略の一環としてクラウドを積極的に受け入れるようになってきています。これにはMicrosoftベースのアプリケーションも含まれます。銀行は本来の事業である銀行業務に注力し、ホスティングのような付随的な作業から解放されることを望んでいます。彼らはクラウドを戦略的な要素として捉えており、 常に変化する規制コンプライアンス環境への対応、 ワークロード、データ、ネットワークに対する最高レベルのセキュリティの維持、機動的な新規参入企業との競争、 インフラの過剰プロビジョニングや過少プロビジョニングを避けるための継続的な適正規模の維持、 そして最後に、データサイロを解消してレガシーシステムを近代化し、特に最近登場しているAI/ML機能などの革新的なテクノロジーを活用できるようにすることを目指しています。
AWSへの移行における主要な検討事項とオプション
AWSでは、銀行がMicrosoftのワークロードをクラウドに移行する動きが続いています。Inforのお客様から、CBSのクラウドバージョンへの具体的な要望があり、これが私たちが協力を始め、今日この話をご紹介できる機会となりました。 移行の旅を始めるにあたって、実際どんな移行でも同じですが、最初に思い浮かぶのはCBSのアーキテクチャ図を作ることかもしれません。しかし、その前にまず立ち止まって、いくつかの質問について考える必要があります。 この場合、検討すべき重要な質問が4つあります。1つ目は、クラウドでのアイデンティティと認証をどのように処理するか。2つ目は、データをどうするか。3つ目は、アプリケーションをどこにデプロイして実行するか。そして4つ目は、ライセンスについてどうするかです。
これらの質問を念頭に置いて、AWSでの選択肢を見ていきましょう。最初の質問に戻ると、Microsoft Active Directoryをどうするかを考える必要があります。多くのアプリケーションがアイデンティティと認証にこれを使用しているからです。
SQL Serverについてはどうでしょうか？クラウドで実行できるのでしょうか？.NETアプリケーションについては？どこで実行するのでしょうか？そして最後に、Microsoftのライセンスについて - 既存のライセンスを持ち込めるのか、それともAWSがライセンスを提供するのか？これはどのように機能するのでしょうか？これらについて一般的な説明をしていきますが、後ほどBradが登壇した際に、CBSとInforのビジネスおよび技術的な観点からの制約と要件について具体的にお話しします。後ほどご覧いただけますが、私たちの決定は、CBSとInforがクラウドでのワークロードのセキュリティ、パフォーマンス効率、信頼性、そしてコストを維持する能力に直接影響を与えます。
まずMicrosoft Active Directoryから始めましょう。 ADに関して最初に自問すべきことは、インフラストラクチャを自分で管理したいのか、それともマネージドサービスを検討したいのかということです。マネージドサービスへの移行を検討する場合、それが移行の障害とならないよう、いくつかの考慮すべき点があります。 マネージドサービスでは、これまでのような制御レベルは得られません。例えば、ドメインやエンタープライズ管理者アクセスは持てません。ドメインコントローラー自体へのRemote Desktop Protocolを介した直接アクセスもできません。これは非常に重要なポイントです。また、ドメインやエンタープライズ管理者グループにユーザーを作成することもできません。そして、ドメインコントローラーにエージェントをインストールする特別なケースや、SQL Serverに特別な設定が必要な場合は、適切な選択肢とはならないかもしれません。
大規模なデプロイメントの場合、マネージドサービスには50万オブジェクトという厳格な制限があります。これにはコンピューター、サービスアカウント、ユーザーが含まれるため、そのような場合はマネージドサービスが適していないかもしれません。ただし、Amazon EC2上で自己管理型のオプションを使用することは可能です。 先ほど述べた制約について考えると、これは正反対の状況です。エージェントのインストールが必要な場合や、より多くの制御が必要な場合、このオプションならそれが可能です。最後に、オンプレミスからクラウドまでをカバーしたい場合も、Amazon EC2での管理が選択肢となります。
データベースについてはどうでしょうか？AWS上でSQL Serverを実行できるのでしょうか？おそらく既にご存知の方もいらっしゃると思いますが、もちろん可能です。私たちには3つのオプションがあります。1つ目は、RDS for SQL Serverで実行できるマネージドサービスです。2つ目は、Amazon EC2上で実行する方法です。そして3つ目は、責任を共有する中間的なオプションとして、Amazon RDS Custom for SQL Serverがあり、AWSが高可用性を担当しながら、必要な設定をカスタマイズすることができます。これらのオプションにはそれぞれ、制御、ライセンス、管理のオーバーヘッドに関する制限があります。
次に、.NETアプリケーションをどこで実行すべきかについて話しましょう。この決定は基本的に2つの観点から考える必要があります。より多くの制御と管理オーバーヘッドを持ちたいのか、それともアプリケーションコードをクラウドにデプロイして管理の手間を気にしたくないのか、という点です。多くの場合、移行がリスクを伴う場合や、開発者がいなくなってコードを変更できない場合、あるいは市場への展開を急ぐ場合には、左側のオプション、つまりAWS Elastic BeanstalkやAmazon EC2が適しています。
WindowsとSQL Serverのライセンスについては、3つのオプションを検討できます。1つ目は、ライセンス込みのインスタンスを購入し、使用した分だけ支払う方法です。マシンを起動すると、マシンとライセンスの料金が発生し、停止すると料金は発生しなくなります。また、既存のライセンスを持ち込むオプションも2つあります。1つ目は、ライセンスモビリティの特典がある場合で、これによりEC2インスタンスを共有テナンシーモードで実行できます。もう1つは、現在のライセンスにライセンスモビリティの特典がない場合でも、Dedicated Hostで実行することで、そのライセンスをAWSに持ち込むことができます。
Infor CBSのクラウド移行における課題と目標設定
これで、私たちが持っているオプションや検討すべき質問事項、そしてAWSで利用可能なオプションについての基礎的な説明が終わりました。ここで、この移行プロジェクトで考慮しなければならなかったビジネス要件の具体的な制約について、Bradにお話しいただきたいと思います。ありがとうございます、Brandon。皆さん、こんにちは。私はInforのCloud ArchitectのBrad Schaufです。私はCBS（Complete Billing System）を専門としています。まず、CBSについてご紹介させていただきます。これは商業銀行、特にTreasury Managementサービスを提供する商業銀行向けのシステムです。
これらのサービスには、ACH送金、小切手の発行、電信送金、ロックボックスサービス、その他多くの種類のサービスが含まれ、合計で2,500種類ものサービスがあります。従来、銀行がこれらのサービスを管理する際、それぞれのサービスを個別に価格設定していたため、請求書が全体像を示さず、顧客体験が断片化されていました。CBSで私たちが目指しているのは、銀行がより多くのサービスを利用したり、これまでとは異なる種類のサービスを活用したりするような行動を促すために、様々なオプションを備えた統一的な価格戦略を提供することです。CBSを使用することで、銀行は単一のグローバルな統合請求書に移行することができます。
CBSは一般的な銀行取引アプリケーションのような取引処理システムではなく、管理用のフロントエンドUIを備えたバッチ処理システムだということを理解しておくことが重要です。日中はデータを受け付けることはできますが、CBSの主な処理は月末に行われ、その時点で特定の銀行の顧客向けに月次の統合請求書を生成します。これには後ほど説明する通り、かなりの計算リソースが必要となります。
Inforについての背景を説明することで、これから私が説明する意思決定についてより理解していただけると思います。Inforにとってクラウドコンピューティングは目新しいものではありません。私たちは業界特化型のクラウドベースソリューションにおけるグローバルリーダーであり、シングルテナントとマルチテナントの両方のオプションを提供するCloud Suiteが主力製品です。様々な理由から、私たちはCBSをシングルテナント型のオファリングに組み込むことを決定しました。最初は再ホスティング戦略を採用して開発を進め、基本的にワークロードをAWSにリフト＆シフトできるようにしました。これにより、コードの変更に集中することができ、後でそれをシングルテナント型のオファリングに移行することができました。
迅速な移行を目指していましたが、合理的な場合にはクラウドネイティブサービスを活用したいと考えていました。この過程で、多くのAWSサービスやCloud Suiteのサービスを検討しました。AWS re:Inventでの発表ということで、AWSサービスについてより詳しく説明させていただきます。アーキテクトとして、私はサーバーを管理するよりもサービスを利用することを好みます。それにより将来的な柔軟性が高まり、IPアドレスやサーバーの心配から解放されて、サービスのパフォーマンスに集中できるからです。再ホスティング戦略に従い、最も単純な選択として、まずは仮想マシン上でAmazon EC2インスタンスを使用することにしました。EC2インスタンスの適切なサイジングに最も時間を費やしましたが、この後Amirebrahim Sotoodehが登壇してより詳しく説明します。
最初に検討したAWSサービスの1つがAmazon RDSでした。このサービスを利用すれば、SQLサーバーやバックアップの管理から解放されると考えました。しかし、私たちのCloud Suiteチームはすでにシングルテナント環境でEC2インスタンス上のSQL Serverを効率的に管理していることがわかりました。CBSはRDSで問題なく動作し、実装も簡単でしたが、私たちの環境がRDSを十分に活用できる状態ではないと判断し、これを将来の目標とすることにしました。次に検討したのがAWS Managed Microsoft ADでした。ディレクトリ内のオブジェクトはそれほど多くありませんでしたが、ドメイン管理者グループへのアクセスが必要で、アプリケーションの要件として特にドメインコントローラーへのアクセスが必要でした。アプリケーションの機能の特定の側面において、このドメインコントローラーへのアクセスが具体的に必要とされていました。
これは重要な決定の1つでしたが、現在のシングルテナント環境アプローチとの一貫性を保つため、Active DirectoryをAmazon EC2インスタンス上で実行することにしました。
次の重要な決定はライセンスに関する検討でした。Inforには多くのWindowsやSQLのライセンスがあり、それらを各サービスに割り当てることもできましたが、その管理作業は後回しにすることにしました。代わりに、EC2インスタンスにバンドルされているWindowsライセンスとSQL Serverライセンスを活用することにしたのです。このアプローチにより、ライセンスの問題を即座に考慮することなく、適切なサイジングに集中できる大きな柔軟性が得られました。さらに、開発環境のように1日8時間だけ稼働する環境や、災害復旧環境のように月1回だけ稼働する環境では、実際の使用時間分のライセンス料金のみを支払えばよいという利点もありました。
さて、ここで私たちが直面した核心的な課題についてお話しします。バッチ処理システムについて特定のSLAターゲットを達成する必要があり、最も負荷の高い期間は月末のLead Nightでした。 大規模なワークロード構成では、15億のアカウントと1億1,000万のトランザクションを処理する必要がありました。標準のSLAでは、この処理を8時間以内に完了することが求められています。8時間というと余裕があるように聞こえるかもしれませんが、これらのサーバーはこの期間中、常にフル稼働状態なのです。最初に大規模ワークロードのテストを行った際、完了までに12時間かかりました。
処理時間を33%削減する必要があることが分かりました。私たちはAWSの同僚たちと協力し、AmirとBrandonからまず最初に求められたのは、既存のパフォーマンス指標からのベンチマークデータでした。しかし、これまでのお客様はすべてオンプレミス環境だったため、環境構成やサーバーサイズ、あるいはEC2インスタンスプロファイルとの比較についての洞察が得られませんでした。
Solutions Architectの役割とパフォーマンス最適化への取り組み
私はAmirとBrandonに次のような課題を提示しました：コードの変更やプラットフォームの変更を一切せずに33%の削減を達成すること。具体的には、パフォーマンス向上のための修正や、SQL Serverから他のソリューションへの移行は行わないということです。それでは、Amirに引き継ぎたいと思います。
2022年3月7日、私は正式にAWSのSolutions Architectとなりました。 まだ3年も経っていませんが、100人以上のSolutions Architectと一緒に仕事をする機会に恵まれました。今日のスピーカー3人全員がSolutions Architectということで、Solutions Architectに関する「2つの真実と1つの嘘」というゲームで今日のセッションを始めるのも面白いと思いました。 Solutions Architectとして、私たちは十分な時間とリソースがあれば何でも可能だと本当に信じています。個人的には、Solutions Architectの意見に異を唱えることはお勧めしません。なぜなら、彼らはいつでも「もっと時間が必要」「もっとリソースが必要」、あるいはその両方を求めてくる可能性があるからです。
私たちに質問をいただくと、ある2つの魔法の言葉でお答えする義務を感じます。その2つの魔法の言葉とは「It depends（場合によります）」です。この言葉を、質問の答えが分からない時の逃げ口上だと思われる方もいらっしゃるかもしれません。しかし、皆さんの質問に対する答えが分からないことよりもっと恐ろしいことがあるのです。それは、間違った答えを提供してしまうことです。
そして3番目に、Solutions ArchitectとSpecialist Solutions Architectは、自分の専門分野について全てを知っているということです。Solutions Architectコミュニティに対する皆さんの先入観を確認する前に、ある話をさせていただきたいと思います。これは、Brad Schauf、Brandon Blincoe、そして私が初めて出会った時の実話です。その始まりを鮮明に覚えています。覚えているのは、Los Angelesの北2時間にあるPine Mountain Clubというところのキャビンでリモートワークをしていた時のことだったからです。あの白い椅子に座って、Bradが初めてInfor CBSについて話してくれた時のことを覚えています。Infor CBSをAWSに移行してSaaSソリューションとして提供する計画と、その過程で直面した課題について話し合いました。
ミーティングが終わりに近づいた時、Bradが「Amir、最後にもう一つ質問していいですか？」と言ったのを覚えています。時計を見ると次の会議の時間が迫っていたので、「Brad、It dependsですね。短い質問ですか、それとも時間がかかりそうですか？」と答えました。彼は短い質問だと言って、こう続けました。「Infor CBSのアーキテクチャについて今分かっていることを踏まえて、コードに触れずにプラットフォームも変更せずに、バッチ処理時間を33%削減することは可能だと思いますか？」私は考えました。SQL Serverのパフォーマンスを最適化する方法はあるはずだし、同僚たちは日々そういった作業をしている。でも、その質問に自信を持って「はい」と答えられる専門家が自分なのだろうか？答えは明確な「ノー」でした。
そこで私は考えを整理して、「Brad、It dependsですね。十分な時間とリソースがあれば何でも可能です」と答えました。皆さんは既に私の名前をご存知で、私がSolutions Architectであることもご存知です。そして注意深く聞いていた方なら、私がSQL最適化について全てを知っているわけではなかったことにもお気づきでしょう。正直に申し上げると、私はSQL最適化について何も知りませんでした。それでも私は、まさにそのInfor CBSチームを支援する任務を任されたのです。具体的な結果についてはまだお話ししませんが、この取り組みは成功したと言えます。そうでなければ、今ここに立ってこの話をしていないでしょう。
これから30-35分かけて、皆さんがこのセッションを出る頃には、ご自身のワークロードでも同様の取り組みを真剣に検討したくなるような理由を、できる限りお伝えしたいと思います。Bradが言ったように、この時点でInfor CBSのパフォーマンスを最適化することは、AWSでSaaSソリューションとして提供するための道のりにおける最も重要な課題だったのです。
パフォーマンステストの実施と段階的な最適化プロセス
非SQLの最適化エキスパートとして、Infor CBSチームを支援するためのゲームプランを考えてみました。最初のステップは比較的簡単でした。これは実際、AWSでの顧客対応において常に意識し、実践するよう推奨されているステップです。それは、ゴールと制約から始めるということです。ここで、Infor CBSのリーダーシップチームは素晴らしい仕事をしたと思います。なぜなら、チームが具体的な目標に集中できるよう、明確で簡潔な目標をいくつか設定することができたからです。すでにご覧いただいたように、目標はコードに手を加えることなく、プラットフォームを変更することなく、バッチ処理時間を33%削減することでした。
ゴールと制約から始めることで、適切なサイジングの推奨事項に関する基本ルールを定めることができます。Infor CBSのケースでは、3つの点を確実にする必要がありました。1つ目は、Infor CBSの実行から収集したすべてのパフォーマンスメトリクスが、EC2サービスの公開された範囲内に収まっていることです。2つ目は、すでにお聞きになった通り、コード変更なし、プラットフォーム変更なしということです。そして3つ目は、これらすべてをコスト意識を持って実行しなければならないということでした。では、私たちの課題の核心部分について考えると、次のステップは何でしょうか？Infor CBSのパフォーマンスに関して、いくつかの決定を下す必要がありました。
どのようなインスタンスで実行するか、どのようなストレージを選択するかを決定する必要がありました。 これらの選択肢にはそれぞれ固有の制限があり、その制限を測定する方法はパフォーマンスメトリクスを通じてでした。 私たちは、選択したオプションの制限を特定し測定するのに役立つパフォーマンスメトリクスから逆算して作業を進めることにしました。
次は、メトリクスを理解することです。非常に大まかに言うと、今日お話しするパフォーマンスメトリクスには3つのカテゴリーがあります。 一般的なカテゴリーについてはすでにご存知かと思いますが、CPUの使用率やメモリの使用率などがこれにあたります。次に、ストレージに関するより細かいパフォーマンスメトリクスがあり、これについては後ほど詳しく説明します。そして、ApplicationやSQL Server特有のメトリクスがあります。
ここで、ストレージのパフォーマンスメトリクスについて、概念を視覚化するのに役立つと思われる例え話を使ってみましょう。ストレージを双方向の道路に例えると、IOPSつまり1秒あたりの入出力は、その道路上の特定の地点を1秒間に両方向に通過する車の数になります。IOサイズは車の大きさ、つまりその車に乗っている乗客の数だと考えてください。この例えでは、スループットは1秒間にその道路上の1地点を通過する乗客の総数となります。IOPSやスループットの制限に達すると、道路が狭くなって渋滞が発生する状況だと考えることができます。Volume Queue Lengthは、この例えでは渋滞で待っている車の数ということになります。
SQL Server環境で利用可能なリソースについて考えてみましょう。具体的には、利用可能なコンピューティング能力、その環境に割り当てられているメモリ量、ネットワークのスループット、そしてもちろんストレージのオプションです。これら4つのリソースのうち3つは、インスタンスタイプによって決定されます。したがって、パフォーマンスの高い環境を実現するための最も重要な決定の1つは、選択するインスタンスタイプということになります。
AWSではストレージは分離されたサービスとして提供されており、インスタンスタイプとは独立して異なるオプションを選択できます。ただし、選択したインスタンスタイプは、利用可能なストレージのオプションにも影響を与えます。ストレージオプションについて詳しく見ていきましょう。先ほどと同じ例えを使うと、通勤時に利用できる道路の種類を想像してみてください。日常的な交通に適した一般道路があり、より高速で安定した走行のために設計された高速道路や自動車専用道路があります。そして一番右には、最高のパフォーマンスと高速走行のために設計されたレース専用トラックがあります。
同様に、AWSのAmazon EBS（Elastic Block Store）には、複数のボリュームタイプが用意されています。一般的な日常用途向けのGeneral Purpose SSD、そしてio2とio2 Block Expressがあります。io2とio2 Block Expressボリュームについて覚えておくべき重要なポイントは、これらがProvisioned IOPSボリュームと呼ばれ、ストレージサイズとは独立してIOPSとスループットを割り当てることができるということです。これらのボリュームタイプ間のパフォーマンスの違いを簡単に見てみましょう。IOPSの観点では、GP3は16,000 IOPSが上限で、io2は最大64,000、io2 Block Expressは256,000 IOPSまで可能です。スループットについては、GP3とio2ボリュームはともに1,000メガビット/秒が上限で、io2 Block Expressは4,000まで対応しています。容量に関しては、GP3とio2はともに16テラバイトが上限で、io2 Block Expressはその4倍の64テラバイトです。これまで説明したこれらのオプションは、すべてAmazon Elastic Block Store（Amazon EBS）の一部です。
AWSの特定のインスタンスタイプで利用可能な、もう1つの種類のストレージがあります。それがインスタンスストアボリュームです。インスタンスストアボリュームについて知っておくべき重要なポイントは、これらが物理的に基盤となるホストに接続されているストレージだということです。そのため、これらのボリュームからより高いパフォーマンスが期待できます。ただし、重要な注意点として、これらのボリュームはエフェメラル（一時的）であり、インスタンスの再起動のたびにデータが失われます。これは、SQL Serverの特定のユースケース、具体的にはSQL ServerのTempDBには最適な選択肢となります。この点については、パフォーマンステストの中でより詳しく説明していきます。
次に、制限要因を理解することについて説明します。これが車の速度計だとして、理論上この車で出せる最高速度は何マイルでしょうか？200マイルです。では、この場合はどうでしょう？今度は、走行している道路によって課される異なる種類の制限が、その車で出せる最高速度に影響を与えています。同様に、SQL Server環境のパフォーマンスを考える際には、異なるレベルで適用されるパフォーマンス制限があることを念頭に置く必要があります。EC2インスタンスレベルで適用される制限があり、EBSボリュームレベルで適用される制限もあります。そしてもちろん、アプリケーション（この場合はSQL Server）レベルでも制限が適用されます。このトピックで覚えておくべき重要なポイントは、複数のレベルでパフォーマンス制限が適用される場合、より小さい方の制限が実際の制限となるということです。
テストラウンドごとの詳細な分析と改善策の実施
いよいよ楽しい部分に入っていきましょう - テスト、適切なサイジング、そして繰り返しです。実際にパフォーマンステストを始める前に、 ワークロードのパフォーマンス指標を収集し、異なるテスト間での状況を確認できるような監視システムが必要になります。Amazon CloudWatchがそのためのツールとなります。ここでは設定方法の詳細には触れませんが、SQL Serverからパフォーマンスデータを取得するためのユースケースについては、具体的なブログ記事で詳しく説明されています。実際、Infor CBSチームにはそのブログ記事だけを共有しましたが、2日後には環境全体が構築され、テストを開始することができました。
テストの内容を見ていきましょう。ただし、テストの結果を説明する前に、 各テストラウンドについて共有する内容のガイドとロードマップを簡単に説明させてください。各テストラウンドを開始する前の、アプリケーションサーバーとデータベースサーバーという2つの主要サーバーのインスタンス構成をご覧いただきます。各ラウンドの目標について説明し、テスト実行後の発見事項を確認し、最後にそれらの発見に基づく推奨事項をご紹介します。
まず、データベースサーバーにはR6i.8XLインスタンスタイプを選択し、 その構成は画面の通りです。重要なポイントとして、16,000 IOPSと250メガビット/秒のスループットを持つ単一のGP3ボリュームを使用しています。バッチサーバーにはM6i.4XLを選択し、その構成も同様に表示されています。ここで疑問となるのは、この初期構成をどのように決定したのかということです。これはベストゲスのシナリオでした。というのも、先ほど説明したように、パフォーマンス指標を持っていなかったためです。そのため、オンプレミス環境との類似マッピングに基づいて環境を構築せざるを得ませんでした。
第1ラウンドのテストの目標は、明らかにAWS上でのInfor CBSの初期パフォーマンスをベンチマークし、 どのようなワークロードを扱っているのかを理解することでした。メモリ集約型のワークロードなのか、それとも IOPS集約型やスループット集約型のワークロードなのかを把握する必要がありました。これから見ていただくのは、 CloudWatchダッシュボードからの実際のテストと実際のスナップショットです。右下に指標の名前が表示され、青色がSQL Server、オレンジ色がバッチサーバーのパフォーマンスデータを示しています。ここでEBSスループットの観点から注目すべき点は、両サーバーの両ボリュームのストレージに250メガビット/秒の制限があったことです。この場合、特にテストの開始時と終了時にピークとなる262で制限を超えていることが分かります。これが発見事項です。明らかに制限を超えています。
推奨事項としては、SQL Serverのスループット制限を1000メガビット/秒に、バッチサーバーを500メガビット/秒に引き上げることでした。 次に、両サーバーのCPUとメモリ使用率を見てみましょう。CPU使用率に関しては、テスト期間中かなりの時間、91.1%のピークを記録しました。メモリについては、使用可能な容量が5メガバイト未満しか残っていませんでした。
ご覧の通り、Batchサーバーでは継続的なCPUとメモリの負荷と競合が観察されました。 これにより、Batchサーバー環境の処理能力を超えつつあることが分かりました。そこで、M7i.8XLにBatchサーバーを変更することを決定しました。これにより、CPUとメモリを2倍にしながら、M seriesインスタンスの最新世代に移行できます。最新世代にアップグレードすると、通常10〜15%のコストパフォーマンスの向上が得られます。
また、先ほど説明したベストプラクティスである、Instance Store Volumeを使用してSQL Serverのtempdbを移行することも実施しました。このようなワークロードには最適な組み合わせだからです。 これを実現するために、Instance Store VolumeをサポートするインスタンスタイプにSQL Serverを変更し、SQL Serverのtempdbのすべてをそのボリュームに移行する必要がありました。
ラウンド2の検証結果を見ていきましょう。 先ほど説明した変更がインスタンス構成に適用されているのが分かります。R6id.8XLに移行し、 tempdbをNVMe（Instance Store Volume）に移動し、SQL ServerのEBSスループットを1000Mbpsに増やしました。Batchサーバーについては、M7i.8XLに移行してCPUとメモリを2倍にし、EBSスループットも2倍にしました。
このラウンドの目標は明確でした。 ラウンド1で見られたスループット制限の超過に対処し、tempdbをInstance Store Volumeに移行した効果を検証し、リソースを2倍にしたBatchサーバーのパフォーマンスを評価することでした。 ラウンド1では、EBSスループットが262Mbpsで制限を超えていました。 ラウンド2では、テスト終盤で833Mbpsに達し、スループットの負荷が軽減されたことを示しています。
処理待ちのI/Oリクエスト数を表すVolume Queue Lengthについては、ラウンド1では5.68でピークを迎えていました。ラウンド2では17.9に達し、多くのI/Oリクエストが待機列に入っていることを示唆しています。 Volume Queue Lengthの値が増加した場合、通常はIOPSに対する負荷、つまりより多くのIOPSを実行する際の制限があることを示しています。 およそ18というピークのVolume Queue Lengthは、SQL ServerのIOPSに競合が発生していることを示しています。
IOPSについて説明しますと、ラウンド1では6,000 IOPSでピークを迎え、ラウンド2では28,100 IOPSに達しました。GP3ボリューム1つあたりのIOPS上限値は16,000です。AWSサービスのパフォーマンスに関して公表されている数値範囲については、それが信頼できる保証された範囲であることを覚えておくことが重要です。より良いパフォーマンスが得られる可能性はありますが、それはサービス側の裁量によるものであり、計画に組み込むべきものではありません。
スループットを増やすことでより多くのIOPSを処理できるようになりましたが、IOPS制限を超過していました。そこで私たちは、SQLのデータボリュームとログボリュームを2つの異なるGP3ボリュームに分割し、それぞれに16,000 IOPSを割り当てることを推奨しました。では、その結果を簡単に見ていきましょう。
CPUとメモリの使用率を確認すると、バッチサーバーのCPU使用率が85.6%でピークを迎えていることがわかります。CPUは確かにハードに稼働していますが、テスト期間中ずっと100%というわけではないので、現時点では問題ありません。しかし、メモリに関しては、バッチサーバーの残りメモリが4メガバイト未満という状況でした。
この結果から、バッチサーバーがメモリ集約型であることが判明しました。テスト実行中のかなりの時間、実質的にメモリを使い切っている状態でした。そこで、バッチサーバーをR7iz.8xlにアップサイズすることを推奨しました。これにより、CPUレベルは維持したまま、バッチサーバーで利用可能なメモリを2倍にすることができます。
ラウンド3のインスタンス変更について、実施した変更点をご覧いただけます。データベースサーバーでは、追加のGP3ボリュームを導入しました。これにより、バッチサーバーに16,000 IOPSのボリュームが2つになりました。また、バッチサーバーをR7iz.8xlに移行し、そのインスタンスで利用可能なメモリを2倍にしました。このラウンドの目標は、追加のGP3ボリュームを導入し、SQLサーバーのデータボリュームとログボリュームを分割することでIOPS超過に対処することでした。さらに、バッチサーバーのメモリ増設の効果についてもテストを行いました。
ラウンド2では、メモリの空き容量が4メガバイト未満でした。Batchサーバーのメモリを倍増させた後、ラウンド3で何が起きたのか見てみましょう。 メモリ使用率のピーク時、つまりBatchサーバーで利用可能なメモリが最も少なくなる時点でも、およそ128ギガバイトのメモリが使用可能な状態でした。Batchサーバーに追加で提供した128ギガバイトは使用されませんでした。
この結果から、追加メモリが活用されていないことは明らかです。そのため、このメモリは不要という結論に至り、Batchサーバーのダウンサイジングを行って R7iz.4xlに戻すことを推奨します。ラウンド2では、単一のGP3ボリュームでVolume Queue Lengthが17.9でした。 ラウンド3では、2つのGP3ボリュームを使用した際に興味深い現象が起きました。2つの異なるGP3ボリュームのVolume Queue Lengthを合計すると、 前回のラウンドで見られた約18という値とほぼ同じになりました。つまり、トラフィックを2つの道路に分散させましたが、渋滞で待機している車の総数は変わらなかったということです。
次にIOPSを見てみましょう。このラウンドでは32,900 IOPSに達しました。2つの異なる GP3ボリュームを使用していても、依然として32,000で頭打ちとなり、最大値を超過している状況です。 より高速なストレージが必要と判断し、すべてを単一のIO2ボリュームに移行することにしました。さらに、アーキテクチャをシンプルにするため、tempdb、 データ、およびログボリュームをすべて1つのIO2ボリュームにまとめ、最大40,000 IOPSに設定しました。
IO2ボリュームは最大64,000 IOPSを提供できますが、様々なレベルで制限が適用されます。私たちが使用しているR6idn.8xlインスタンスは、インスタンスレベルで40,000 IOPSが上限となるため、40,000 IOPSを最大値として設定する必要がありました。参考までに、これらのテストを開始した時点では、SQL Server用にR7ファミリーを選択することができました。しかし、 最初のラウンドのテストを思い出してください。SQL ServerのtempdbをInstance Storeボリュームに移行することを推奨しました。ただし、R7は利用可能でしたが、Instance Storeボリュームを提供していませんでした。そのため、Instance Storeボリュームを提供するR6インスタンスから始めることにしました。今回、すべてをIO2ボリュームに移行することにしたため、Instance Storeボリュームは不要となり、実際にR 7に移行することが可能になりました。これは、もはやInstance Storeボリュームが必要なくなったためです。では、実施した変更点について説明させていただきます。
現在、SQL Serverには40,000 IOPSの単一ボリュームがあり、BatchサーバーではR7iz-4XLインスタンスタイプに移行することでCPUとメモリを半分に削減しています。目標は、観察されたIOPS制限の超過に対処し、今回はBatchサーバーのダウンサイジングの効果をテストすることです。
結果を見ていきましょう。ラウンド3では、32コアのvCPUで86.7%のCPU使用率を記録しました。 ラウンド4では89.7%に達し、バッチサーバーのコア数を半分に減らしたにもかかわらず、CPU使用率はわずか3%の増加に留まりました。これは明らかに正しい判断でした。コア数を半分に減らしても、CPU使用率の増加はわずか3%だったからです。
EBS IOPSについては、ラウンド3で32,900 IOPSを記録し、ラウンド4では38,100 IOPSを達成しました。これは、今回の一連のテストの中で最高のIOPS数であり、そのインスタンスで利用可能な40,000 IOPSの上限に近づいています。そして、次の部分が私のお気に入りです。ラウンド2では、Volume Queue Lengthが17.9でした。ラウンド3では、2つの異なるボリュームで約18を維持していました。ラウンド4では、Volume Queue Lengthが劇的に減少して6.3になりました。これは、Volume Queue Lengthが66%減少したことを意味します。実質的にトラフィックの待ち行列を66%削減できたのです。
では、これらの変更が当初の目標であったバッチ処理時間の短縮にどのような影響を与えたのか見てみましょう。Bradが言及したように、ラウンド1では処理時間が12時間強でした。ラウンド4の後には、これを6.5時間まで短縮し、48%の時間削減を達成しました。
コスト最適化とプロジェクトの成果
次の論理的なステップは、すべてが適切なコスト範囲内で動作することを確認することでした。SQL Server環境でコストを削減しようとする場合、SQL Serverのライセンスが最適な検討対象となります。その理由を説明しましょう。AWSでR6i-8XLインスタンスを実行するコストは、Linuxオペレーティングシステムで約4,000ドルです。Windows Serverのライセンスを追加すると5,000ドルになります。SQL Server Standard Editionを追加すると8,000ドルに、SQL Server Enterprise Editionでは月額14,000ドルになります。
Infor CBSチームと協力してこれらのオプションを評価した結果、幸いにもSQL Server Standard Editionでの運用が可能であり、ダウングレードによって大幅なライセンスコストの削減を実現できることがわかりました。この取り組みの成果を見ると、バッチ処理時間を48%削減し、当初の目標である33%削減を15%上回ることができました。SQL Server Standard Editionへの移行により、SQL Serverのライセンスコストを74%削減し、総保有コストを約24%削減することができました。
適切なサイジングが重要であることは、誰もが同意できるでしょう。急激な増減は、良い結果をもたらしません。このプロジェクト全体で、AWSとInforのチームが費やした時間は合計で100時間未満でした。ここでは4回のテストについて説明しましたが、実際には8回のテストを実施しました。そのうち4回分は、テスト間でのパラメータのリセットやデータのリセットの漏れなど、現実世界での問題により破棄せざるを得ませんでした。AWSでこれらのテストを実行するためのインフラコストは、数千ドル程度でした。
Infor CBSチームの成功は、高度なSQLの最適化の専門家たちが何ヶ月もかけて、何十万ドルものコストをかけて一発で成功を収めたわけではありません。彼らが成功したのは、素早く失敗し、何度も失敗し、安価に失敗することができたからです。私はチームに与えられる最高の贈り物は、素早く失敗し、何度も失敗し、安価に失敗する機会を提供することだと信じています。このアプローチを実践することで、チームメンバーに権限を与え、達成感をもたらすことができると、私は実際に目の当たりにしてきました。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion