[SAP] Orica 社の事例 – Azure における S/4HANA 基盤アーキテクチャの設計


執筆者: Cameron (MSFT SAP Program Manager)

このポストは、2018 年 8 月 23 日に投稿された Orica’s S/4HANA Foundational Architecture Design on Azure の翻訳です。

 

この記事では、Cognizant と Orica の S/4HANA 環境刷新プロジェクトの成功事例をご紹介します。グローバルな S/4HANA 環境をどのようにして Azure に展開し、稼働させたのかをご覧ください。この 2 社は、2018 年 8 月の本稼働まで 2 年間にわたってこの移行プロジェクトに取り組み、数々の決断を下してきました。この記事では、それらの重要なポイントについても詳しく解説しています。

 

ここからの内容は、Cognizant の SAP クラウド & テクノロジ コンサルティング事業のグローバル責任者を務める Sivakumar Varadananjayan 氏が執筆したものです。Varadananjayan 氏は、Orica のデジタル トランスフォーメーション プロジェクトのテーマである「Simple, Standard, Single SAP」の 4 つの S を冠した 4S プログラムの始動時からプリセールス責任者として携わり、現在はチーフ アーキテクトとして、Orica における Azure での S/4HANA 導入をサポートしています。

Cognizant は、信頼できるテクノロジ アドバイザーおよびマネージド クラウド プラットフォーム プロバイダーとして 2 年間にわたってこのプロジェクトに参加し、Microsoft Azure で運用される SAP S/4HANA と他の SAP アプリケーション向けの可用性に優れた、拡張性の高い、障害に強い IT プラットフォームを構築してきました。当社のお客様である Orica (英語) は、工業用爆薬と発破システムを手がける世界最大手のメーカーとして、鉱山業、採石業、石油・ガス採掘業、建設業の市場に製品を提供しています。また、金抽出用シアン化ナトリウムの大手サプライヤーとしても知られるほか、採掘とトンネル工事に関する地上支援サービスの専門家派遣も行っています。このプロジェクトの一環として、Cognizant (英語) は Orica の SAP S/4HANA プラットフォームを Microsoft Azure に新たに構築し、マネージド パブリック クラウド プラットフォーム サービス (PaaS) を提供しています。

Cognizant がクラウドの基盤作りに取り掛かったのは、2016 年 12 月でした。この記事では、当社が採用したベスト プラクティスをご紹介します。Azure での SAP ワークロードのデプロイメントを計画している企業の皆様には、きっと参考にしていただけるはずです。

取り上げるトピックは以下のとおりです。

  • 移行先インフラストラクチャのアーキテクチャ設計
    • 適切な Azure リージョンの選定
    • 書き込みアクセラレータ
    • 高速ネットワーク
  • SAP アプリケーションのアーキテクチャ設計
    • 動的なクラウドに対応した SAP 環境のサイジング
    • 容量の拡大と縮小
  • HA/DR 設計 (SUSE HA クラスター)
    • SUSE クラスター
    • Azure Site Recovery (ASR)
  • クラウドのセキュリティ
    • ネットワーク セキュリティ グループ
    • 暗号化 – ディスク、ストレージ アカウント、HANA データ ボリューム、バックアップ
    • ロールベースのアクセス制御
    • リソースのロックによる削除防止
  • 運用と管理
    • レポート
    • コスト
    • クローン環境の作成
    • バックアップと復元

 
移行先インフラストラクチャのアーキテクチャ設計

障害に強いインフラストラクチャ アーキテクチャを設計するには、最終的な形を細部まで具体的に想定しておく必要があります。まず行うべきは、重要なビジネス要件を把握し、設計原則を定めることです。そうすることで目指すべき方向が明確になり、設計について適切に優先順位を付けながら選択できるようになります。このプロジェクトの設計原則では、SAP アプリケーションのホスティングに適した Azure リージョンのほか、オペレーティング システム、データベース、エンド ユーザーのアクセス方法、アプリケーションの統合戦略、高可用性、ディザスター リカバリー戦略、サービス中断時のシステムの重要性とビジネスへの影響の定義、環境の定義などについて、どのようなものが望ましいかを規定しました。設計段階では、マイクロソフトと SUSE の担当者、その他にも重要なプロジェクト関係者に参加してもらい、お客様のビジネス要件とセキュリティ要件に基づいて移行先アーキテクチャを完成させました。インフラストラクチャ設計の一部として、Azure リージョン、ExpressRoute、Orica の MPLS WAN との接続、DNS と Active Directory ドメイン コントローラーの統合といった重要な基本要素も最終決定しました。

インフラストラクチャの準備を検討する際には、VNet の設計 (サブネットの IP アドレス範囲)、ホストの名前付け規則、ストレージ要件、コンピューティング要件に基づく初期の VM タイプなど、さまざまなトピックが議題に上がりました。Orica の 4S プログラムでは、Web 層、アプリケーション層、データベース層の 3 層構造のサブネットを採用しました。この 3 層構造のサブネットは、サンドボックス、開発、プロジェクト テスト、品質管理、運用のそれぞれの環境に構築しているため、Orica ではサブネット レベルでのきめ細かなネットワーク セキュリティ グループ (NSG) をセキュリティ要件に沿って柔軟にデプロイすることができます。また、層構造のサブネットを明確に定義したことで、個々の VM ホストに対して複雑な NSG を定義せずに済みました。

Web 層では SAP Web ディスパッチャー用 VM をホストし、アプリケーション層では SAP セントラル サービス インスタンス用 VM、プライマリ アプリケーション サーバー インスタンス用 VM、追加のアプリケーション サーバー インスタンス用 VM をホストし、データベース層ではデータベース用 VM をホストしています。これとは別に、ジャンプ サーバーやドメイン コントローラーなどの基本的な管理コンポーネント用のサブネットも配置されています。

適切な Azure リージョンの選定

Azure は複数のリージョンで運用されていますが、そこで欠かせないのが、メイン ワークロードをデプロイするプライマリ リージョンの選定です。SAP アプリケーションのホスティングに最適なリージョンを選ぶ作業はきわめて重要です。どこが最適なのかを判断するには、(1) 実際の施設に影響する法的要件や規制要件、(2) レイテンシを最小限に抑えるための企業 WAN の PoP (ポイント オブ プレゼンス) とエンド ユーザーの近さ、(3) VM と他の Azure サービスの可用性、(4) コストについて検討する必要があります。VM の可用性の詳細については、この記事の「SAP アプリケーションのアーキテクチャ設計」セクションの「動的なクラウドに対応した SAP 環境のサイジング」を参照してください。

高速ネットワーク

高速ネットワークを使用すると、VM との間でシングル ルート I/O 仮想化 (SR-IOV) が可能になり、ネットワークのパフォーマンスが大幅に向上します。この高パフォーマンスのパスによってデータ パスからホストがバイパスされ、サポートされる VM タイプの場合、最も要件の厳しいネットワーク ワークロードで使用しても、レイテンシ、ジッター、CPU 使用率が軽減されます。高速ネットワークを使用しない場合、VM に出入りするすべてのネットワーク トラフィックについてホストと仮想スイッチをスキャンする必要があります。
高速ネットワークなら、ネットワーク トラフィックは、VM のネットワーク インターフェイス (NIC) に到達した後、直接ゲスト VM に転送されます。仮想スイッチで適用されるネットワーク ポリシーはすべてオフロードされ、ハードウェアで適用されます。高速ネットワークは HANA のパフォーマンスの向上と予測に欠かせない機能ですが、すべての VM タイプやすべてのバージョンのオペレーティング システムがサポートされているわけではありません。この点は、インフラストラクチャ設計時に考慮に入れる必要があります。また、高速ネットワークでは同一 Azure Virtual Network (VNet) 内におけるネットワーク通信のレイテンシが最小限に抑えられる点に注意が必要です。つまり、複数の Azure VNet をまたぐネットワーク通信のレイテンシ全体への影響はわずかでしかないということです。

ストレージ

Azure には、Standard、Premium、Managed (VM 用) の Azure Disk Storage や、Azure Blob Storage など、複数のストレージ オプションが用意されています。この記事の執筆時点では、Azure はパブリック クラウド サービス プロバイダーとして唯一、単一インスタンス仮想マシンに対する 99.9% の SLA を保証しています (Premium Disk を使用する VM を実行している場合のみ)。単一インスタンス仮想マシンに対する SLA を受けることが目的であるなら、Standard Disk よりも Premium Disk を選択する方がコスト面では非常に有益です。そのため、アプリケーションやデータベース ストレージ用のすべての VM に Premium Disk を使用することをお勧めします。Standard Disk はデータベース バックアップの保存に適しており、Azure Blob は VM のスナップショットやバックアップの転送に使用されます。それらのバックアップの転送や保存は、データの保持ポリシーに沿って行います。SLA を活用して 99.9% 以上の稼働率を確保するには、可用性向上テクニックを使用します。詳細については、この記事のセクション「高可用性とディザスター リカバリー」を参照してください。

書き込みアクセラレータ

書き込みアクセラレータは、Azure Managed Disk の Premium Storage を使用する M シリーズ VM でのみ提供されるディスク機能です。名前が示すとおり、この機能の目的は Azure Premium Storage に対する書き込みの I/O レイテンシを短縮することです。書き込みアクセラレータは、HANA のような最新のデータベースのパフォーマンス要件を満たしながらデータベースの Redo ログをディスクに書き込めるようにする場合に最適です。運用環境で利用するには、SAP HANA H/W Configuration Check Tool (HWCCT) を使用して、最終的な VM インフラストラクチャのセットアップを検証する必要があります。この分野の専門家が検証結果について評価し、VM が運用ワークロードの実行に耐えられる性能を有していること、さらに SAP による認定を受けていることを確認する必要があります。

 
SAP アプリケーションのアーキテクチャ設計

SAP アプリケーションのアーキテクチャ設計は、SAP アプリケーション、システム、コンポーネントを構築する際に採用すべき原則に基づいて行います。SAP アプリケーションのアーキテクチャをうまく設計するためには、実装の範囲に含まれる SAP アプリケーションをリストアップする必要があります。

また、パブリック クラウド インフラストラクチャでの SAP システムの展開と運用に関する重要な情報が以下の SAP ノートで提供されているため、参照することをお勧めします。

  • SAP Note 1380654 – SAP support in public cloud environments
  • SAP Note 1928533 – SAP Applications on Azure: Supported Products and Azure VM types
  • SAP Note 2316233 – SAP HANA on Microsoft Azure (Large Instances)
  • SAP Note 2235581 – SAP HANA: Supported Operating Systems
  • SAP Note 2369910 – SAP Software on Linux: General information

SAP 環境の OS と DB の組み合わせ

SAP 製品の可用性マトリックスを参照すれば、アーキテクチャの範囲内の各 SAP アプリケーションが、使用を検討しているオペレーティング システムとデータベースをサポートしているかどうか調べられます。メンテナンスや管理の容易さという観点からは、SAP アプリケーション用のデータベースは 2 種類までとしたほうがよいでしょう。SAP アプリケーションの大半は SAP HANA データベースをサポートしています。また、SAP HANA はマルチテナント データベースに対応しているため、使用する SAP アプリケーションのほとんどは SAP HANA データベース プラットフォームで実行することをお勧めします。SAP HANA データベースをサポートしていないアプリケーションを使用する場合は、他のデータベースを組み合わせる必要があります。なお、SAP S/4HANA アプリケーションは HANA データベースでのみ実行可能です。Orica のプロジェクトでは、HANA をサポートしている SAP アプリケーションはすべて HANA で実行し、それ以外のアプリケーションについては SQL Server を採用しました。これは設計原理に合致しており、データベースのメンテナンス、バックアップ、HA/DR 構成も容易になります。

SAP HANA 2.0 はメインストリームに移ろうとしている段階であるため (ただし、S/4HANA 1709 以降には必須)、対応するオペレーティング システムは SAP HANA 1.0 ほど多くはありません。たとえば、HANA 1.0 には "通常" の SUSE Linux Enterprise Server で十分でしたが、現在 SUSE で唯一 SAP HANA 2.0 に対応しているのは、SUSE Linux Enterprise Server for SAP Applications です。そのため、Orica にとってはライセンスへの影響がありました。Azure ではライセンス持ち込み型サブスクリプションのイメージしか提供していないからです。したがって、Orica はオペレーティング システムのライセンスを自身で用意する必要がありました。

アーキテクチャのタイプ

SAP では、NetWeaver プラットフォームを基盤として、セントラル システム (同一ホスト内にプライマリ アプリケーション サーバーとデータベースを配置) または分散システム (別々のホストにプライマリ アプリケーション サーバー、追加アプリケーション サーバー、データベースを配置) のいずれかのアーキテクチャでアプリケーションをデプロイできます。どのタイプのアーキテクチャにするかを決める際には、費用対効果、ビジネスの重要度、アプリケーションの可用性などの要件を徹底的に精査する必要があります。また、各 SAP アプリケーションに必要なサンドボックス、開発、品質管理、運用、トレーニングといった環境をいくつ用意するかも決める必要があります。これらを判断するうえで主な基準となるのが、プロジェクトの立ち上げ時に計画した、変革に関するガバナンスです。たとえば、運用環境には高度な可用性が求められますが、そのようなビジネス クリティカルなシステムについては必ず、高可用性クラスターが構成された分散システム アーキテクチャでデプロイすることを検討します。可用性はパブリック クラウド インフラストラクチャではなおさら重要です。従来の "高額な" オンプレミス システム (IBM pSeries など) に比べて、頻繁に VM で障害が発生しやすいためです。一昔前なら、サーバーで障害が発生することはめったになく、可用性が多少低くても差し支えありませんでした。しかし、パブリック クラウドでは比較的高い確率でサーバー障害が起きます。そのため、稼働可能な時間が重要な場合は、ビジネス クリティカルなシステムの可用性を高める必要があります。ビジネス クリティカルなシステムでも、そうでないシステムでも、パラメーターを設定して、予期せぬサーバー再起動が発生した場合にアプリケーションやデータベースを自動的に起動できるようにしておくことをお勧めします。たいていの場合、ビジネス クリティカルな SAP アプリケーションの大半で、目標復旧時点 (RPO) と目標復旧時間 (RTO) に基づいてディザスター リカバリー機能を構築することが推奨されます。

Cognizant は、Orica のプロジェクトにおいて 4 つのシステム環境と分散 SAP アーキテクチャを設計しました。HANA MDC を採用して既定ですべての SAP アプリケーションを HANA で実行する場合に、セントラル システム アーキテクチャでは対応しきれないため、SAP アプリケーション サーバーと DB サーバーを分離することにしたのです。また、HANA データベースの SID は、それぞれの HANA データベースに含まれるテナントに関係なく設定しました。これは、将来にわたって使い続けられるようにするためと、今後必要に応じてテナントの HANA ホストを変更できるようにするためです。また、Orica のプロジェクトではカスタム スクリプティングを実装し、自動的に SAP アプリケーションが起動するようにしました。この自動再起動は、一元的に管理されたパラメーター ファイルで制御 (有効化または無効化) できるようになっています。高度な可用性は運用環境と品質管理環境に実装しました。ディザスター リカバリー機能は、Orica のビジネス要件に定められている目標復旧時点 (RPO) と目標復旧時間 (RTO) に沿って構築しました。

動的なクラウドに対応した SAP 環境のサイジング

SAP アーキテクチャのタイプが決まったら、次は、各コンポーネントのデプロイメントに必要な仮想マシンの適正数について検討します。インフラストラクチャの観点から、この段階で仮想マシンのサイズを決める必要があります。同時接続ユーザー数またはスループットに基づいたサイジングを行える Quick Sizer (英語) のような、SAP の標準的なツールを活用できます。ここでのベスト プラクティスは、スループット ベースのサイジングです。Quick Sizer のスループット ベース サイジングでは、アプリケーションおよびデータベース コンポーネントの SAPS 値 (スループットの指標) とメモリ必要量、HANA データベースを使用する場合のメモリ必要量を算出できます。スプレッドシートにまとめられた表形式の重要なサイジング情報と、標準的な SAP ノートを参照することで、Azure クラウド インフラストラクチャにおける同等の VM タイプを割り出すことができます。マイクロソフトは新しい VM についても定期的に SAP による認定を取得しているため、常に最新の SAP ノートから最新情報を入手することをお勧めします。多くの場合、HANA データベースには、データベースのサイズに応じて E シリーズ VM (メモリ最適化タイプ) や M シリーズ VM (大容量のメモリ最適化タイプ) が必要になるでしょう。この記事の執筆時点では、E シリーズと M シリーズでサポートされているメモリの最大容量は、それぞれ 432 GB、3.8 TB です。E シリーズは、Azure で以前から提供されていた GS シリーズよりも費用対効果が高くなっています。ここで、サイジング ツールから得られた VM タイプが、SAP 環境のホスティングに使用する予定の Azure リージョンで提供されているかどうかを調べる必要があります。場合によっては、地理的条件によって一部の VM タイプが提供されていない可能性もあります。必要な VM タイプがすべて利用できる適切な地理的環境と Azure リージョンを慎重に選択することが不可欠です。ただし、パブリック クラウドには拡張性と柔軟性があります。環境をプロビジョニングする際に、ピーク時を正確に想定したサイジングを行う必要はありません。CPU、メモリ、ディスクの使用率などの指標をモニタリングし、実際の使用状況に応じて、常に余裕を持って SAP システムをスケールアップまたはスケールダウンできるようにしましょう。同じ VM シリーズ内であれば、VM を停止して、VM サイズを変更し、VM を起動するだけで、簡単にスケールアップやスケールダウンが可能です。VM のサイズ変更手順は、通常 2 ~ 3 分もあればすべて終わります。そのときどきで、Azure で提供されている性能の範囲内にシステムが収まるよう心がけましょう。たとえば、1 TB の M シリーズを作成した後で 1.7 TB のインスタンスが必要となった場合、リサイズは簡単にできるためそれほど手間はかかりません。しかし、システムを 3.8 TB (M シリーズの最大サイズ) 以上に拡張することになるかどうか不明な場合はリスクが高く、困難な事態を招きやすくなります (このようなケースに対応するために、L インスタンスが提供されています)。また、購入前に実際のハードウェア容量が正確に把握できる場合は、Reserved Instances を活用することでコストをさらに抑えられます (過剰なコミットメントも避けられます)。


 
高可用性とディザスター リカバリー

SAP S/4HANA のようなビジネス クリティカルなシステムの可用性を稼働率 99.9% 以上のレベルにまで高めるには、明確な高可用性アーキテクチャの設計が欠かせません。Azure では、1 つのリージョンの中の 1 つの可用性ゾーン内の 1 つの可用性セットにデプロイした VM クラスターに対して、99.95% の可用性が提供されます。Azure の SLA では、コンピューティング VM を同一リージョン内の複数の可用性ゾーンにデプロイしている場合に 99.99% の稼働率が保証されます。この水準を確保するために、SAP アプリケーションをホストするリージョン内で可用性ゾーンを活用することをお勧めします。Azure の可用性ゾーンは現在もマイクロソフトによってロールアウト中であることにご注意ください。マイクロソフトでは、いずれすべてのリージョンで利用できるようになるとしています。また、SAP の SPOF (単一障害点) となるコンポーネントは、SUSE クラスターのようなクラスターにデプロイする必要があります。99.95% の可用性を実現するには、このようなクラスターを 1 つの可用性セット内に配置する必要があります。Azure のインフラストラクチャ レベルで高可用性を確保するには、すべての VM を可用性セットに追加し、Azure 内部ロード バランサー (ILB) に接続します。そこに、(A)SCS クラスター、DB クラスター、NFS も含めます。また、アプリケーション サーバーの冗長性を確保するために、少なくとも 2 つのアプリケーション サーバー (プライマリ アプリケーション サーバーと追加アプリケーション サーバー) を可用性セットにプロビジョニングすることをお勧めします。Cognizant、マイクロソフト、SUSE の 3 社のコラボレーションにより、マルチノード iSCSI サーバー構成をベースとしたソリューションが完成しました。Orica の SAP アプリケーション向けに構築されたこのマルチノード iSCSI サーバーの HA 構成は、このような構成が Azure プラットフォームにデプロイされた初の事例となりました。

高可用性を確保していても SAP コンポーネントの機能停止を防げなかった場合に備えて、前述のとおり、Premium Storage Disk を使用した VM をプロビジョニングすることをお勧めします。それにより、単一 VM インスタンスに対する SLA を活用することができます。Orica のプロジェクトでは、アプリケーションとデータベースのボリューム用にすべての VM で Premium Disk を使用しています。SLA の対象とするにはこの方法しかないからです。結果として、パフォーマンスと一貫性も向上しました。

SUSE クラスターについては、次のセクションで詳しく解説します。

SUSE クラスターの HA 向けセットアップ

(A)SCS レイヤーの高可用性は、SUSE HA Extension クラスターで実現しています。DRBD はレプリケーション向けのテクノロジですが、SAP カーネル ファイルなどのアプリケーション ファイルのレプリケーションには使用していません。これはマイクロソフトの推奨事項に基づいた設計で、SAP もサポートしています。DRBD レプリケーションを使用しないのは、同期レプリケーションを構成する際にパフォーマンスに関する問題が出てくる可能性があり、そのような同期レプリケーションを構成し、アプリケーション レイヤーでの障害復旧レプリケーションとして ASR を有効化した場合に、復旧が保証されない可能性があったためです。NFS レイヤーの高可用性についても、SUSE HA Extension クラスターを使用しています。データのレプリケーションには DRBD テクノロジを使用しています。これもマイクロソフトによる推奨事項で、単一の NFS クラスターを使用して複数の SAP システムに対応することで、設計全体をシンプルにしています。

高可用性のテストは、VM の単純なクリーン シャットダウン以外にもあらゆる障害状況を想定し、徹底的に実施する必要があります。たとえば、VM の停止をシミュレーションするには halt コマンドを使用します。VM のネットワーク スタックでの問題をシミュレーションするには、NSG のファイアウォール規則を追加します。

Cognizant では、Orica がマルチ SID SUSE HA クラスター構成の最初のお客様となったことを嬉しく思っています。

 

SAP 向け HA 構成の技術的な詳細については、こちらの記事で解説されています。Azure では、SUSE Linux Enterprise Server (SLES) に Pacemaker クラスターをセットアップする場合に SBD デバイスを使用することが推奨されています。詳細はこちらの記事をご覧ください。仮想マシンを 1 つ追加で用意することが予算的に難しい場合は、Azure Fence エージェントを使用することもできます。その場合、リソースの停止に失敗した際や、クラスター ノードが互いに通信できない状態に陥った際、フェールオーバーに 10 ~ 15 分かかるというデメリットがあります。

アプリケーションの可用性を確保するうえでもう 1 つ重要なのが、何らかの障害が発生した際に、適切に策定されたディザスター リカバリー プランに沿って優れたアーキテクチャの DR ソリューションが実行されることです。

Azure Site Recovery (ASR)

Azure Site Recovery を使用すると、機能停止中でも業務関連のアプリとワークロードの実行状態を維持し、ビジネス継続性を確保できます。Site Recovery では、物理マシンおよび仮想マシンで実行されているワークロードがプライマリ サイトからセカンダリ サイトにレプリケートされます。フェールオーバー時には、クラスター構成や DNS に適切な変更が加えられた後で、セカンダリ サイトでアプリが起動しアクセスできるようになります。プライマリ サイトが再度実行状態になったら、そこにフェールバックできます。Orica での本稼働が始まった時点では、ASR はテストされていませんでした。SLES 12.3 のサポートがマイクロソフトから一般提供されたタイミングが、カットオーバーの直前だったからです。現在はこの機能を評価している段階です。本稼働の次のフェーズには、DR ソリューションとして使用する予定です。

 
クラウドのセキュリティ

物理層、サーバー層、ハイパーバイザー層、ネットワーク層、コンピューティング層、ストレージ層の各レイヤーおけるセキュリティなど、従来のセキュリティの概念のほとんどはクラウドのセキュリティ全体にも応用できます。基本的には、各層がパブリック クラウド プラットフォームから提供され、サードパーティの IT セキュリティ認定プロバイダーによって監査が行われます。クラウドでは、クラウド プロバイダーから提供されるさまざまな機能やカスタマイズと、クラウドにホストしているアプリケーションに搭載されているセキュリティ機能を活用して、クラウドにホストしたアプリケーションを保護します。

ネットワーク セキュリティ グループ

ネットワーク セキュリティ グループ (NSG) では、ネットワーク レイヤーに適用される一連のルールによって、Azure にホストしている VM のトラフィックや通信を制御できます。Azure では、運用環境、非運用環境、インフラストラクチャ、管理環境、DMZ 環境に、それぞれ別の NSG を関連付けることができます。NSG ルールをモジュール化し、理解と実装が容易になるように定義するための戦略を策定することが重要です。ルールを制御するには、スクリプト プロシージャを実装する必要があります。そうしないと、不要なルールが無駄に増えるばかりで、ネットワーク通信に関連する問題のトラブルシューティングが困難になってしまいます。

Orica のプロジェクトでは、1 つのルール内で送信元と送信先の一定の範囲に対して複数のポートを追加することで、NSG ルール数の最適化に取り組みました。NSG を関連付けた時点で、変更承認プロセスも導入しました。NSG ルールはすべてカスタム フォーマットのテンプレート (CSV) で管理しており、実際に Azure に設定する際にはスクリプトから使用します。プライマリ サイト、DR サイトなど、複数リージョンの複数 VNet に対して手動で設定するのは非常に困難だと思われたため、このような方法を取っています。

ストレージ アカウントと Azure Disk の暗号化

Azure Storage Service Encryptiocn (SSE) は、どのストレージ アカウントでも使用が推奨されている機能です。これを使用すると、Azure Storage 内の BLOB が暗号化されます。データは、SSE を有効した後にストレージに書き込まれたものが暗号化されます。Managed Disk では既定で SSE が有効化されています。

Azure Disk Encryption では、Windows の業界標準である BitLocker 機能と Linux の DM-Crypt 機能によって、OS とデータ ディスクのボリュームが暗号化されます。Azure Key Vault と統合されているため、Key Vault サブスクリプションでディスク暗号化キーとシークレットを制御、管理できます。OS ボリュームを暗号化すると、ストレージに保存中のブート ボリュームのデータが保護されます。データ ボリュームを暗号化すると、ストレージに保存中のデータ ボリュームが保護されます。データは、Azure Storage に永続化される前に自動的に暗号化され、取得される前に暗号化が解除されます。

保存中の SAP データの暗号化

SAP アプリケーションについては、データベースの暗号化によって保存中のデータを暗号化します。SAP HANA 2.0 と SQL Server では、保存中のデータの暗号化がネイティブにサポートされているため、データの窃盗対策としてセキュリティを強化できます。加えて、両方のデータベースのバックアップはパス フレーズによって暗号化、保護され、読み取りのみ可能となり、認証ユーザーのみが利用できます。

Orica のプロジェクトでは、Azure Storage Service Encryption と Azure Disk Encryption の両方を有効にしました。さらに、SAP HANA 2.0 に保存中の SAP データの暗号化を有効にし、SQL Server データベースについては TDE 暗号化を有効にしました。

ロールベースのアクセス制御 (RBAC)

Azure Resource Manager ではきめ細かなロールベースのアクセス制御 (RBAC) モデルが提供され、リソース (VM、ストレージ) 単位で管理特権を割り当てられるようになっています。サービス開発チームやアプリ開発チームに対して RBAC モデルを使用すると、職務を分離、管理でき、特定のリソースで作業をするために必要なユーザーまたはグループに対して必要最小限のアクセス権を付与できます。これは、最小権限の原則に則っています。

リソースのロック

管理者はサブスクリプション、リソース グループ、またはリソースをロックして、社内の他のユーザーが誤って重要なリソースを削除したり変更したりできないようにする必要があります。ロックを設定する場合、「削除不可」または「読み取り専用」というレベルに設定できます。それらのロック レベルは、Azure Portal でそれぞれ [Delete] と [Read-only] と表示されます。ロールベースのアクセス制御とは異なり、リソースのロックでは、すべてのユーザー (所有者のアクセス権限を持つユーザーを含む) が意図的または偶発的にリソースを削除するのを防止できます。削除不可では、許可されているユーザーであればリソースの読み取りと変更は可能ですが、削除はできません。読み取り専用では、許可されているユーザーはリソースの読み取りが可能ですが、削除や更新はできません。このロック レベルは、許可されているすべてのユーザーに対して、閲覧者ロールのアクセス許可のみを付与することと似ています。Orica のプロジェクトでは、Azure インフラストラクチャの重要なリソースにロックを設定し、安全性を強化しました。

 
運用と管理

Cognizant は、Microsoft Azure のクラウドを介して、サービスとしてのマネージド プラットフォーム (mPaaS) を Orica に提供しています。SAP システムをパブリック クラウドで運用するうえでは、自動起動および自動シャットダウンのスケジューリング、自動バックアップ管理、監視とアラート生成、高度な自動監視といったメリットがありますが、同社ではそれらを活用して、専門的な運用と管理にかかるコスト全体を最適化しています。運用と管理に関する推奨事項としては、次のようなものがあります。

Azure のコストとレポート

Microsoft の子会社である Cloudyn からライセンスが供与される Azure Cost Management では、クラウドの使用状況と、Azure リソースや他のクラウド プロバイダー (AWS、Google など) に関する費用を追跡できます。クラウドでは一定期間のリソース使用量に対して料金が発生するため、使用状況と費用を把握することはクラウド インフラストラクチャを利用するうえで非常に重要です。使用量が契約の範囲を超えた場合、すぐさま予定外の超過料金が発生することもあります。

レポートを活用することで、費用に注意を払いながら、クラウドの使用量、コスト、利用傾向を分析、追跡できます。時間の経過を追ったレポートを活用すれば、通常とは異なる異常な使用状況を察知することができます。
より詳細な品目ごとのデータは、EA 向けポータル (https://ea.azure.com) で確認できます。こちらのデータは、Cloudyn のレポートよりも柔軟性が高く便利です。

バックアップと復元

専門的な運用における可用性の管理に関する第一の要件は、インフラストラクチャの障害、データの破損、または災害などによるシステムの完全停止といった要因から偶発的にデータが消失することのないようシステムを保護することです。高可用性やディザスター リカバリーなどの考えによって、インフラストラクチャ障害による影響は軽減されますが、データの破損や損失などの事態に対処するには、堅牢なバックアップおよび復元戦略が欠かせません。バックアップを取っておくことで、システムの損壊が発生した場合にアプリケーションを稼働状態に復元でき、ディザスター リカバリーのシナリオに「最終防衛ライン」を構築できます。バックアップおよび復元手順の第一の目標は、元の稼働状態にシステムを復元することです。

バックアップおよび復元戦略の重要な要件は、次のとおりです。

  • バックアップは復元可能であること
  • データベースのネイティブなバックアップおよび復元ツールを使用することが望ましい
  • バックアップは保護され暗号化されること
  • 保持期間の要件を明確に定義すること

VM のスナップショットのバックアップ

Azure のインフラストラクチャでは、VM のスナップショットを取得する機能を使用して、VM (使用されているディスクも含む) のバックアップをネイティブに提供しています。VM のスナップショットのバックアップは、Azure のバックアップ コンテナーに保存しています。このバックアップ コンテナーは Azure Storage アーキテクチャの一部で、既定で地理的に冗長化しています。ちなみに、Microsoft Azure では、テープのような従来のデータ保持メディアはサポートされていません。クラウド環境でのデータ保持には、Azure Storage アーキテクチャの一部である Azure バックアップ コンテナーや Azure Blob などのテクノロジを活用しています。一般的に、Microsoft Azure にプロビジョニングするすべての VM (データベースを含む) は VM スナップショット バックアップ計画に含めるべきです。ただしその頻度は、環境の重要度やアプリケーションの重要度によって異なります。また、Azure Storage アカウント レベルで暗号化を有効化することによって、Azure バックアップ コンテナーに保存しているバックアップが、Azure サブスクリプション外からアクセスされても暗号化された状態になっているようにすることをお勧めします。

データベースのバックアップ

ファイル システムとデータベース ソフトウェアは、前述の VM スナップショット プロセスで復元できますが、データベースを格納している VM をデータベースの一貫性が維持された状態で復元できるとは限りません。したがって、データベースのバックアップは、データベースの復元性を確保するうえできわめて重要です。環境内のデータベースは、すべてデータベースの完全バックアップに含めることをお勧めします。そのスケジュールは、ビジネスの重要性とアプリケーションの要件に沿って調整する必要があります。データベースのバックアップを取得したら、データベース バックアップ ファイルの一貫性をチェックします。これは、データベース バックアップの復元性を確保するための方策です。

データベースの完全バックアップの他に、定期的にトランザクション ログ バックアップを実行することをお勧めします。運用環境の場合はその頻度を高めて、復旧ポイントの要件に対応する必要があります。非運用環境であればバックアップの頻度は比較的低くなります。

データベースの完全バックアップとトランザクション ログ バックアップは、どちらもオフライン デバイス (Azure Blob Storage など) に転送し、データ保持要件に沿って保持する必要があります。データベースのバックアップはすべて、ネイティブのデータベース バックアップ暗号化手法 (サポートされている場合) を使用して暗号化することをお勧めします。SAP HANA 2.0 では、ネイティブのデータベース バックアップ暗号化がサポートされています。

データベース バックアップの監視と復元テスト

適切な頻度とスケジュールでバックアップが実行されているか確認するには、バックアップを監視する必要があります。これはスクリプトで自動化できます。障害、データ損失、データ破損が発生したときのアプリケーションの復元性を確保するには、バックアップの復元テストを実行します。

 
まとめ

Cognizant の SAP クラウド移行プロジェクトでは、SAP、マイクロソフト、SUSE の協力を得ながら、SAP 環境を Azure にデプロイするためのベスト プラクティスを活用し、Orica の 4S プログラムに合ったベスト プラクティスを確立してきました。この記事では、Azure における SAP 環境の設計に関連する重要なトピックをご紹介しました。皆様の参考になれば幸いです。皆様からのご意見もお待ちしております。

 

Comments (0)

Skip to main content