Amazon S3によるHA対応の持続可能で耐久性の高いSAPドキュメントおよびデータアーカイブ – Part2

はじめに

このブログシリーズのPart 1では、SAP Content Serverを使用しているお客様が、Amazon S3をドキュメントストアとして活用して、コスト効率が高く、堅牢でスケーラブルなドキュメント管理ソリューションを構築する方法を探求しました。このブログシリーズの第2部では、高可用性(HA)を実装することで、お客様がAmazon S3上のSAP Content Serverの信頼性を向上させる方法を共有します。

SAP Content Serverにおける高可用性が重要な理由

Uptime Instituteの「2025 Annual Outage Analysis Report」によると、組織の54%が最近の重大な障害で10万ドル以上のコストが発生したと報告しており、20%は1インシデントあたり100万ドルを超えるコストを経験しています。この中断は組織全体に波及し、注文処理、カスタマーサービス業務、コンプライアンス要件に影響を与えます。ミッションクリティカルなSAPワークロードを実行している組織にとって、SAP Content Serverはドキュメント管理業務のバックボーンを形成します。

ビジネスプロセスが購買発注書、請求書、契約書、規制文書への即座のアクセスに依存している場合、SAP Content Serverへの中断はビジネス運営に影響を与える可能性があります。したがって、SAP Content Serverが高可用性で構成され、潜在的なハードウェア、ソフトウェア、またはネットワーク障害にもかかわらず運用可能でアクセス可能な状態を維持することが非常に重要です。

提案アーキテクチャ

このブログシリーズのPart 1では、SAP Content Serverに保存されたコンテンツのファイルシステムとしてAmazon S3 File Gatewayを設定する方法を説明しました。コンテンツリポジトリを作成し、SAP ERPがコンテンツリポジトリにアクセスできるように構成しました。さらに、SAP MaxDBからAmazon S3へのコンテンツ移行のステップバイステップガイドを提供しました。

S3 File Gatewayサービスには99.9%の可用性SLAがあり、これは月間最大43分の計画外ダウンタイムに相当します。この提案されたHAソリューションは、組織がこの可用性SLAを必要とする場合にのみ必要です。このHAソリューションを使用できる3つの異なるシナリオを、以下の図1、2、3に示します。

図1: RISE with SAP on AWSに接続された高可用性SAP Content Server

図2: オンプレミスSAP ERPサーバーに接続されたAWS上の高可用性SAP Content Server

図3: AWSネイティブSAP ERPサーバーを使用した高可用性SAP Content Server

提案ソリューション

図1では、ソリューションアーキテクチャは、RISE with SAPがNetwork Load Balancer (NLB)を介してSAP Content Serverを通じてS3 File Gatewayに接続するHA設計を実装しています。NLBは、SAP Content Serverからプライマリ S3 File Gatewayインスタンスへのリクエストを効率的にルーティングし、S3バケットに接続されたローカルファイル共有を通じてドキュメントにアクセスします。このアーキテクチャは、S3 File Gatewayエンドポイント用のDomain Name Service (DNS)名を持つNLBを活用し、シームレスなフェイルオーバー機能を確保します。フェイルオーバーが発生すると、NLBは自動的にセカンダリアベイラビリティゾーン(AZ)のアクティブなS3 File Gatewayにトラフィックをリダイレクトし、業務の中断なくビジネスドキュメントへの継続的なアクセスを維持します。

以下は、2つの別々のS3 File Gatewayをインストールおよび構成し、同一のファイル共有を作成し、Git上のカスタムpacemakerリソーススクリプトを通じて高可用性を確保するためのステップバイステップガイドです。

カスタムリソースは、NLBターゲットグループ内のS3 File Gatewayファイル共有を管理するためのpacemakerリソースエージェントを実装します。これは、異なるAZ間のインスタンス間で自動的にフェイルオーバーすることにより、S3 File Gatewayの高可用性を提供するように設計されています。このアーキテクチャは、Overlay IPアドレスを使用する代わりに、NLBのネイティブターゲットグループ機能を活用して、2つのAZ間でS3 File Gatewayインスタンスに直接トラフィックをリダイレクトします。

ステップ1: 2つのS3 File Gatewayをインストールおよび構成

異なるAZに2つの別々のS3 File Gatewayをインストールおよび構成することから始めます。このセットアップにより、冗長性が確保され、データアクセシビリティが向上します。両方のゲートウェイがS3バケットにマッピングされていることを確認してください。

図4: 2つのS3 File Gatewayの構成

ステップ2: 同一のファイル共有を作成

次に、同じS3バケットを指す同一のファイル共有を作成します。このプロセスにより、両方のAmazon S3 File Gatewayが同じデータにシームレスにアクセスできるようになります。これらのファイル共有の権限が、アプリケーションからのアクセスを許可するように正しく設定されていることを確認してください。

図5: S3 File Gatewayをファイル共有に向ける

SAP Content ServerへのエントリポイントとしてNLBが必要です。NLBの構成を以下に示します。

図6: NLBの作成

図7: NLBターゲットグループの作成

NLBと関連するターゲットグループの作成については、このドキュメントを参照してください。

ステップ3: NLB DNS名を使用してNFS共有をマウント

NLB DNS名を使用してSAP Content ServerにNFS共有をマウントします。このアプローチにより、クライアントに単一のアクセスポイントが提供され、接続が簡素化され、フォールトトレランスが向上します。NLBが両方のS3 File Gatewayにリクエストを転送するように構成されていることを確認してください。

図8: SAP Content Server内のAmazon S3 File Gatewayマウントポイント

ステップ4: 高可用性クラスターフレームワークソフトウェア(SLES/RedHat)を構成

このGitに従ってpacemakerクラスターを構成します。クラスターが正常に構成されたら、「pcs status」を介してクラスターステータスを確認します:

図9: SAP Content Server HAクラスターステータスの確認

ステップ5: EC2 Auto Recoveryを有効化

最後に、インスタンスのEC2 Auto Recoveryを有効化します(新しく作成されたEC2インスタンスではデフォルトで有効になっていることに注意してください)。この機能は、システム障害が検出されたときにインスタンスを自動的に回復し、ノードがそれぞれのAZで利用可能な状態を維持します。Amazon CloudWatchアラームを構成して、インスタンスのヘルスを監視し、必要に応じて回復アクションをトリガーします。

これらの手順に従うことで、高可用性プラクティスを活用した回復力のあるストレージソリューションを確立し、異なるAZ間で重要なデータへの継続的なアクセスを確保できます。

ステップ6: テスト

フェイルオーバー前:

トランザクションME22N(購買発注変更)を例として、PDFドキュメントを添付できます。

図10: ME22NによるPDF添付

図11: S3にアップロードされたPDFドキュメント

SAP Content Serverのセカンダリノードへのフェイルオーバーは、いくつかの方法でトリガーできます。AWS Fault Injection Simulator (FIS)は、AWSワークロードで制御された障害注入実験を実行することにより高可用性(HA)テストを自動化する完全マネージド型サービスを提供し、実際の障害が発生する前にアプリケーションの回復力を検証し、災害復旧手順の弱点を特定できます。システム管理者は、現在のアクティブノードで「pcs node standby」や「pcs resource move」などのpacemakerクラスターコマンドを使用してプロセスを開始できます。

あるいは、現在のSAP Content Serverノードで/usr/sapマウントのI/Oを無効にする(例: 「umount」経由)などの障害条件を導入することで、フェイルオーバーを手動で調整またはシミュレートできます。フェイルオーバー中、両方のS3 File Gatewayインスタンスは動作し続けますが、NLBターゲットグループの登録が変更され、セカンダリFile Gatewayインスタンスにトラフィックが向けられます。このアーキテクチャは、NLBが新しくアクティブになったS3 File Gatewayインスタンスにトラフィックをリダイレクトするため、ビジネス運営の中断なくドキュメント管理システムへの継続的なアクセスを維持しながら、シームレスな移行を保証します。

図12: 中断検出後、クラスターステータスはプライマリノードが停止していることを示しています

クラスターリソースはセカンダリノードで起動しています:

図13: プライマリノードが停止した後、セカンダリノードがクラスターによって起動されています

Content ServerがS3 File Gatewayと共にセカンダリノードで正常にフェイルオーバーすると、図14のように表示されます。

図14: セカンダリノードが正常に起動したことを示すクラスターステータス

以前のプライマリホストでは、S3 File Gatewayがマウントされなくなっていることがわかります。

図15: 以前のプライマリノードでS3 File Gatewayマウントポイントがマウントされなくなりました

新しいプライマリホスト(セカンダリノード)では、S3 File Gatewayがマウントされていることがわかります。

図16: 新しいプライマリノードにマウントされたS3 File Gatewayマウントポイント

最後に、フェイルオーバー後にトランザクションME22Nを介してSAP購買発注添付ファイルの確認を繰り返し、失われていないこと、およびSAP ERPから引き続きアクセスできることを確認します。

図17: フェイルオーバー後のME22NでのPDF添付ファイルの表示

SAP Content ServerのHAにおけるS3とEFSの考慮事項

AWS上でSAP Content Serverをアーキテクトする際、Amazon EFSとS3 File Gatewayの選択には、それぞれの明確な強みを慎重に検討する必要があります。両方のソリューションが高い耐久性とクロスリージョン機能を提供しますが、S3 File Gatewayベースのアーキテクチャは、主にS3の強力なバージョニング機能を通じて際立っています。これはデータ保護にとって重要な利点です。このバージョニング機能により、誤って削除または破損したファイルのポイントインタイムリカバリが可能になります。これは、ファイルの削除または破損が即座に永続的になるEFSベースのソリューションでは利用できない機能です。両方のサービスがコスト最適化のためのインテリジェントなデータ階層化と同様のクロスリージョンDR機能を提供するようになりましたが、S3のバージョニングは本質的に組み込みのバックアップメカニズムを提供し、別個のバックアップソリューションを維持する複雑さとコストを削減します。データリカバリとバージョン管理が重要な要件である組織、特にドキュメントの以前のバージョンを復元する機能が不可欠なコンプライアンス重視の環境では、S3 File Gatewayアーキテクチャがより包括的なデータ保護戦略を提供します。最終的な選択は特定のビジネス要件に依存しますが、S3 File Gatewayは、高可用性とパフォーマンスと並んで、きめ細かなデータリカバリ機能を優先する組織にとって特に魅力的です。

コスト見積もり

このブログシリーズのPart 1では、S3 File Gatewayの2つのコスト見積もりについて説明しました。1つ目の例はContent Serverデータベースサイズが500GBの場合、2つ目の例は5TBのデータベースの場合です。これらの価格見積もりをHAを含めるように拡張すると:

1. SAP Content Server EC2インスタンス(r7i.xlarge)の数を1から2に増やす
2. EBSストレージボリューム(100GB)の数を1から2に増やす
3. S3 File Gatewayの数を1から2に増やす
4. NLBを追加

表1: 価格比較

AWS Calculator リンク 1a, 1b, 2a, 2b

HAを使用した5TBデータベースの場合、コストは$542から$656に増加します。同様に、HAを使用した500GBデータベースの場合、$124から$239に増加し、HAの追加がコストを大幅に増加させないことを示しています。

上記のコストにはオペレーティングシステム関連のサブスクリプションは含まれていないことに注意してください。これらは、SUSE Linux Enterprise Server for SAP ApplicationsやRed Hat Enterprise Linux for SAPなどのAWS Marketplaceで確認できます。

結論

S3 File Gatewayを使用したSAP Content Serverの高可用性ソリューションの実装は、AWS Well-Architected Frameworkの信頼性の柱で言及されているように、運用の回復力を維持し、ビジネス継続性を確保することを目指す組織にとって不可欠です。概説された手順に従うことで—複数のS3 File Gatewayのインストールと構成、同一のファイル共有の作成、NLBの利用、Git内のpacemaker用カスタムリソーススクリプトの利用、EC2 Auto Recoveryの有効化—企業は、潜在的な中断に耐える堅牢でスケーラブルなアーキテクチャを作成できます。

システムパフォーマンスと回復力を管理するプロアクティブなアプローチは、ダウンタイムに関連するリスクを軽減するだけでなく、厳格なサービスレベル契約もサポートします。AWSのインフラストラクチャを活用することで、組織はデータの耐久性とアクセシビリティを確保しながら、ドキュメント管理機能を強化できます。インフラストラクチャの進化に伴ってシステムのフォールトトレランスを維持し、災害復旧メカニズムが効果的であることを検証するために、スケジュールされたダウンタイム中にAWS FISを使用してHAテストを定期的にスケジュールし、自動化することをお勧めします。

企業がクラウド環境への移行を進める中、これらのHAプラクティスの採用は、重要なSAPワークロードを保護し、デジタル時代における運用効率を推進する上で極めて重要になります。適切にアーキテクトされたHAソリューションに投資することで、組織は現代のITランドスケープの複雑さを自信を持ってナビゲートし、SAPシステムが利用可能でパフォーマンスの高い状態を維持できるようにします。

SAP on AWSディスカッションに参加

お客様のアカウントチームとAWSサポートチャネルに加えて、お客様はre:Post – AWSコミュニティのための再構想されたQ&Aエクスペリエンス – を活用できます。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できる議論や質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。

謝辞

このブログへの貢献について、Ferry Mulyadi、Derek Ewell、Spencer Martensonに感謝します。

本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文はこちらです。