SAP on AWSクラウド設計入門

Rahul Kabraは、Amazon Web Services(AWS)のパートナーソリューションアーキテクトです。

SAPワークロードをAWS上に移行することを真剣に検討し始めると、AWS上のSAPアーキテクチャはどのようにすべきか、オンプレミスやプライベートクラウドで稼働する場合とどこが違うのか、ビジネスにどういった利点があるのか、おそらく気になってくるでしょう。この入門用のブログでは、これらのトピックの多くに触れ、AWS上へのSAPワークロードの移行および運用に向けた準備を整えるための重要な情報をお伝えします。

AWSがもたらす俊敏性と拡張性をSAPワークロードで実際に活用するために、AWS上のSAPランドスケープの設計では、考え方を少し変える必要があります。また、SAPアーキテクチャが様々なAWSサービスをどのように活用し、これまでに比べて可用性が高く、セキュリティが強化された環境が提供されているかを理解することも重要です。SAP on AWSの概要を理解するために、様々なアーキテクチャのコンポーネントを探ってみましょう。

SAP関連の主要なAWSサービス

以下が、SAPワークロードの展開を始めるために知っておいたほうがよい主要サービスの一部です：

Amazon VPC – Amazon Virtual Private Cloud(Amazon VPC)は、AWSクラウドの論理的に隔離された区画を提供し、すべてのAWSリソースを展開します。このサービスは、関連して許可されたネットワークトラフィックだけがVPCに出入りできるよう制御する仮想ネットワーキングの機能とセキュリティを提供します。SAPのためのVPC設計およびアーキテクチャパターンの詳細については、以前投稿したブログ「SAP on AWSにおけるVPCサブネットのゾーニングパターン」を参照してください。
Amazon EC2 – Amazon Elastic Compute Cloud(Amazon EC2)は、SAPアプリケーションサーバーとデータベースをインストールできる仮想ホストを提供します。AWSは、小規模で多目的のインスタンスからSAP HANAのようなインメモリーワークロードを実行できる大容量メモリーのインスタンスまで、SAPワークロードを実行するために認定された複数のインスタンスファミリーを提供しています。
Amazon EBS – Amazon Elastic Block Store(Amazon EBS)は、AWSが提供するブロックベースのストレージサービスであり、SAPアプリケーションおよびデータベースに関連するデータ、ログファイルおよびバックアップボリュームを格納するために使用します。AWSでは複数のEBSボリュームタイプを用意しており、SAPアプリケーションのSAPS、IOPS、スループット要件に合わせて活用することができます。
Amazon EFS – Amazon Elastic File System(Amazon EFS)は、多数のEC2インスタンスから接続できる共有ファイルシステムを提供します。このファイルストレージは、/usr/sap/transや/sapmnt/<SID>などの共有ファイルをマウントする必要があるSAPスケールアウト構成で特に役立ちます。
Amazon S3 – Amazon Simple Storage Service(Amazon S3)は、スケーラブルで耐久性の高いオブジェクトベースのストレージサービスで、SAPアプリケーションのバックアップとスナップショットの保存に使用できます。
Amazon Glacier – このサービスは、スケーラビリティが高く、耐久性に優れ、コスト効率の高いオブジェクトストレージで、コンプライアンスや規制上の理由から長期的なバックアップ、アーカイブ、データ保管に使用できます。
IAM – AWS Identity and Access Management(IAM)は、AWSユーザーとグループの作成および管理に使用します。また、IAMロールによりAWSリソースへのアクセスを安全に制御することができます。
CloudWatch – Amazon CloudWatchは、AWSリソースの監視サービスです。SAPワークロードのリソース利用状況を収集するとともに、AWSリソースの変更に自動的に対応するためのアラームを作成するのに重要です。
CloudTrail – AWS CloudTrailは、AWSアカウント内で行われたすべてのAPI呼び出しを記録します。APIコールに関する重要なメトリックを取得し、SAPリソースの証跡作成を自動化できる非常に有益なサービスです。
AWS CLI – AWSコマンドラインインターフェイス(CLI)は、コマンドラインまたはスクリプトを使用して様々なAWSサービスを管理、操作するために使用できるツールです。このブログ後半の”AWS自動化”の項でいくつかのAWS CLIコマンドの例を確認できます。
Route 53 – Amazon Route 53は、スケーラビリティと可用性の高いAWS上のDNSサービスです。ホステッドゾーン、トラフィックポリシーやドメインを作成したり、AWS以外のリソースにも接続することができます。

AWSサイジングと性能

AWSプラットフォームであれば、セルフサービス方式で正しいタイプとサイズのコンピューティングリソースを展開でき、ハードウェアに大きな初期投資をする必要はありません。AWSに移行することの主な利点の1つに、ビジネスニーズの変化に合わせてリソースを調整できる拡張性と柔軟性が手に入ることが挙げられます。例えば、AWSは、SAPランドスケープをお客様の近くで安全かつ高可用な方法で運用できるよう、16のリージョンと42のアベイラビリティゾーンからなるグローバルフットプリントを提供しています。従来のオンプレミスの構成と異なり、AWSクラウドにおいては、以下に示すようにコンソールでの数クリックの操作や、簡単なAPI呼び出しで、SAP用EC2インスタンスのサイズを変更できます。

AWSマネジメントコンソールから既存のEC2インスタンスのサイズ変更

お客様が必要とする大量のリソースをすぐに利用でき、また使った分のお支払いで済みます。これにより、インフラストラクチャの設計者は、新しいプロジェクトのコンピューティング/メモリーのサイジング要件を決定する際に、バッファを加味したり推測したりすることが不要になります。また、月末や決められた期間のような特別なイベントの間だけ、既存のホストへの容量の追加やSAPアプリケーションまたはデータベース層を拡張することが容易にできます。AWSでは、リソース要件を満たすためにメモリー最適化、コンピュート最適化のインスタンスタイプを提供しており、SAP社と密に連携してどちらもSAP認定を取得しています。SAP認定EC2インスタンスのリストは、SAPノート1656099を参照してください(SAPノートの閲覧にはSAP Support Portalのユーザーが必要です)。

AWS上でSAPアプリケーションを設計するということは、すべてのSAPアプリケーションを常に稼働させる必要はないということです。サンドボックス、トレーニング、デモシステムなど、重要ではないSAPシステムのほとんどは、使用していないときには停止することができ、コストを削減できる可能性があります。

AWS上で性能を実現するための1つに、ストレージの設定方法があります。EBSボリュームはアベイラビリティゾーン内で複製されるため、データ損失から保護されています。このような理由から、EBSボリュームで最大限の性能を出すためには、RAID 0によるストライピングでよいです。これは大半のオンプレミス環境では不可能です。様々なEBSボリュームタイプと性能特性の詳細については、ブログ「SAP HANA on AWSの展開 – どのような選択肢が？」も参照してください。これらのEBSボリュームは、HANA以外のデータベースにももちろん使用できます。

AWS自動化

AWSはクラウドオートメーションのリーダーであり、基盤となるリソースをプログラム的にスクリプト化して、予測可能かつ繰返し可能な方法で操作、拡張するための複数の選択肢を提供しています。スクリプトの実行により、SAPアプリケーションサーバーの新規作成、バックアップやスナップショットの取得、最初から新しいインスタンスを構築するなど、SAPの操作を自動化できます。

稼働中のSAP HANAデータボリュームのスナップショットをバックアップ用に取得し、それらのボリュームを復元することがいかに簡単かを示す例をいくつか紹介します。これらのコマンドは容易に作成することができ、crontabやその他の時間駆動のジョブスケジューラツールからバックアップ/リカバリーの操作スクリプトの一部として簡単に実行できます。

例1: 稼働中のHANAデータボリュームのスナップショット取得

SAP HANAインスタンスの停止：
sudo su – <sid>adm -c "HDB stop"
ファイルシステムの静止：
umount /hana/data

インスタンスにアタッチされているSAP HANAボリュームのIDを識別：

aws ec2 describe-volumes --region=us-west-2 --filters Name=attachment.instance-id,Values=i-03add123456789012 Name=tag-value,Values="HANA*" --query 'Volumes[*].{ID:VolumeId,Tag:Tags}'

Response:

[
    {
        "Tag": [
            {
                "Value": "HANA_root",
                "Key": "Name"
            }
        ],
        "ID": "vol-071111111111111"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #1",
                "Key": "Name"
            }
        ],
        "ID": "vol-082222222222222"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #2",
                "Key": "Name"
            }
        ],
		"ID": "vol-0733333333333"
     }
]

SAP HANAボリュームのスナップショットを取得：
aws ec2 create-snapshot --region=us-west-2 --volume-id vol-07222222222222 --description "HANA Server Data volume #1"; aws ec2 create-snapshot --region=us-west-2 --volume-id vol-08333333333333 --description "HANA Server Data volume #2
SAP HANAデータボリュームのマウント(この操作はスナップショットがPending状態になれば可能)：
mount /hana/data
SAP HANAを起動：
sudo su - <sid>adm -c "HDB Start"

例2: スナップショットからデータを復元し、既存のホストにアタッチ

スナップショットから新しいボリュームを作成：
aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
EC2インスタンスに新しく作成したボリュームをアタッチ：
aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
読込処理を最適化するためにボリュームの初期化(本番環境では強く推奨)：
fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
SAP HANAデータに関連付けられた論理ボリュームをマウント：
mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
SAP HANAを起動：
sudo su - <sid>adm -c "HDB Start"

SAP on AWSで自動化を活用する方法は他にもあります：

Amazon Machine Images(AMI)を使用してSAPインスタンスの新しいコピーを作成できます。
AWS CloudFormationを使用して新しいSAPインスタンスの作成を自動化、AWS Quick Startを活用してクラウド内に新しいSAP HANA環境の展開を実現できます。

複数のアベイラビリティゾーンおよびまたはリージョンを使った可用性と災害対策

従来のオンプレミス構成のSAPシステムでは、同じ物理データセンター内で高可用性(HA)を取る必要がありました。対照的に、AWSは同じリージョン内の複数のアベイラビリティゾーンにまたがったHAを構成できます。アベイラビリティゾーンは、物理的に隔離されたデータセンターの集合体で、ネットワークのレイテンシーが低く、同じ地理的リージョンに接続されています。いくつかのお客様にとっては、この構成で災害復旧(DR)シナリオとしても十分ですが、そうでない場合、TCOの度合いによって国や都市の異なる2つ目のリージョンの利用といった複数の選択肢を用意しています。以下のSAP分散アーキテクチャの例をご覧ください。

AWS上のSAP分散アーキテクチャ

SAP運用

オンプレミス環境と比較して、AWSではAmazon CloudWatchやAWS CloudTrailなどの監視サービスを使うことができ、SAPシステムの運用においてこれまで以上の透明性と説明責任が得られます。AWSリソースへのきめ細かいセキュリティとアクセス制御には、IAMロールとポリシー、セキュリティグループ、そしてネットワークACLを使うことができます。

監視サービス – CloudWatchやCloudTrailのようなサービスは、リソース使用率を監視するのにも役立ちます。CloudWatchを使用すると、ハードウェア障害が発生した場合に、インスタンスを監視して自動的に復旧するアラームを作成できます。詳細はAWSドキュメントをご覧ください。
セキュリティ – IAMはAWSリソースへの洗練されたアクセス制御を可能にするだけでなく、AWSアクセスキーをコピーすることなく、異なるサービス間の安全な通信を可能とするロールも作成できます。詳細はAWSドキュメントをご覧ください。
バックアップ – Amazon S3連携をサポートするバックアップツールのいずれかを使用する場合、S3バケットに直接データベースをバックアップできます。そうでない場合は、AWS上で既存のバックアップツールを使用して、EBSボリュームにファイルをエクスポートしてからAmazon S3と同期することもできます。

AWS簡易見積りツール

AWSでは、ハードウェアと運用コストを包括的に把握することが難しいオンプレミスの世界とは異なり、オンデマンドやリザーブドインスタンスを含むEC2インスタンスの様々な支払い方法とインフラストラクチャのコストをマッピングするツールを提供しています。

次のステップ

SAP on AWSの詳細については、以下のリソースをご覧ください：

SAP on AWSホワイトペーパーを読む – SAP on AWSのアーキテクチャと展開オプションについて詳しく知るための素晴らしい資料です。
SAP on AWSブログを読む – SAP関連の様々なトピックに踏み込んだいくつかのブログがあります。
AWSトレーニングクラスに登録する – AWSでは、様々なAWSサービスを素早く習得するための優れたトレーニングリソースを提供しています。AWSテクニカルエッセンシャルのようなクラスは、これからAWSを開始する方には非常に役立ちます。
AWS認定資格を取得する – AWSソリューションアーキテクトのアソシエイトまたはプロフェッショナル認定の取得は、AWS上にSAPおよびSAP以外のアプリケーションを導入するためのアーキテクチャやベストプラクティスの手引きとして非常に役立ちます。
コンサルティングパートナーに連絡する – 日頃から深くお付き合いのあるコンサルティングパートナーがいる場合は、AWS上へのSAP移行についても相談してみてください。

– Rahul

翻訳はPartner SA 河原が担当しました。原文はこちらです。

Amazon Web Services ブログ