SAP HANA に最適化された次世代 ERP の登場 従来の SAP Business Suite SAP S/4HANA 基幹系 情報系 基幹系 + 情報系 SAP GUI SAP Business Suite ERP CRM SRM SCM PLM BI Tools SAP Fiori, S/

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾン ウェブ サービス ジャパン株式会社 パートナー ソリューション アーキテクト

河原 哲也 2016/6/3

基幹系システムのThe New Normal

～SAP on AWS～

従来のSAP Business Suite

SAP HANAに最適化された次世代ERPの登場

SAP S/4HANA Any DB DWH BI Tools 基幹系 情報系

SAP Business Suite

ERP CRM SRM SCM PLM

コピー

SAP GUI

SAP HANA SAP Business Suite

基幹系＋情報系

Simplified Suite

コードプッシュダウン（一部）

SAP Fiori, S/4HANA Analytics

CDS View シンプル化 SAP HANA(インメモリー)を前提に再設計 基幹系(OLTP)と情報系(OLAP)の融合 アプリケーション層がボトルネック 基幹系(OLTP)と情報系(OLAP)は別々

昨年の今ごろ

• SAP Business Suite on AWSの

本稼働認定は2012年11月 • SAP ERPの国内導入は約2,000社 (H/W更新は5~7年が一般的)

クラウドは今やSAPにおいてもニューノーマル

そして、今年は • 128 vCPUs / 1,952 GiBメモリー • SAP HANAに最適

SAP S/4HANA on AWSが本格化

出典：SAPニュースルーム

http://global.sap.com/japan/news-reader/index.epx?articleID=24569

本日お伝えしたいこと

• X1インスタンスのSAP認定詳細

本日お伝えしたいこと

• X1インスタンスのSAP認定詳細

Amazon EC2 – X1インスタンス

インスタンスタイプ

x1.32xlarge

の仕様

• プロセッサー: Intel Xeon E7-8880 v3 (2.3 GHz) x 4 ソケット,

64 コア / 128 vCPUs

• メモリー: SDDC+1を実現した1,952 GiB

• インスタンスストレージ: 2 x 1,920 GB SSD • ネットワーク帯域幅: 10 Gbps

SAP認定 – SAP HANA IaaS Platforms

シングルノード構成で、

1,952

GiBメモリーの

OLAP

と

OLTP

両方に

唯一対応 (2016年6月3日現在)

出典：CERTIFIED SAP HANA® HARDWARE DIRECTORY

SAP認定 – SAP NetWeaver Platforms

セントラル構成で、

131,500

SAPS /

24,060

SDユーザー

を達成 (Cert: 2016021)

出典：SAP Standard Application Benchmarks in Cloud Environments http://global.sap.com/campaigns/benchmark/appbm_cloud.epx

これまでのSAP認定EC2インスタンス群

10ギガビット 拡張ネットワーキング m4.10xlarge m4.4xlarge m4.2xlarge m4.xlarge m4.large c4.8xlarge c4.4xlarge c4.2xlarge c4.xlarge c4.large c3.8xlarge c3.4xlarge c3.2xlarge c3.xlarge c3.large r3.8xlarge r3.4xlarge r3.2xlarge r3.xlarge r3.large 0 10,000 20,000 30,000 40,000 50,000 0 5 0 1 0 0 1 5 0 2 0 0 2 5 0 S APS メモリー[GiB]

X1インスタンスが加わったことで...

m4.10xlarge m4.4xlarge m4.2xlarge m4.xlarge m4.large c4.8xlarge c4.4xlarge c4.2xlarge c4.xlarge c4.large c3.8xlarge c3.4xlarge c3.2xlarge c3.xlarge c3.large r3.8xlarge r3.4xlarge r3.2xlarge r3.xlarge r3.large x1.32xlarge 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 90,000 100,000 110,000 120,000 130,000 140,000 0 2 0 0 4 0 0 6 0 0 8 0 0 1 , 0 0 0 1 , 2 0 0 1 , 4 0 0 1 , 6 0 0 1 , 8 0 0 2 , 0 0 0 S APS メモリー[GiB]

すべてのSAPワークロードを、on AWSで

SAP S/4HANAの必要メモリー • XS/S (128GB-256GB) = 48% • M/L (512GB-1TB) = 38% • XL/XXL (2TB-48TB) = 14% X1インスタンス(x1.32xlarge) のシングルノード構成で、

100

%に近いお客様の SAP S/4HANA環境をカバー

出典：SAPPHIRE NOW Keynote - Your Road to SAP S/4HANA and Beyond http://events.sap.com/sapandasug/en/session/26970

本日お伝えしたいこと

• X1インスタンスのSAP認定詳細

SAP HANA アプライアンス (H/W)

SAP HANAも必要なときに、必要なだけ

SAP HANA on AWS

数千倍のスピード感で利用可能

業者に連絡 見積り・発注 受け入れ準備 納品・設置 構築・設定 稼働 Webから数クリックで稼働 数カ月 ～1時間 _{その他のメリット} • スタートアップ費用が不要 • スペック変更が容易 • 世界中で利用可能 など

AWS CloudFormation

テンプレート AWS CloudFormation スタック JSON形式ファイル パラメータの定義 リソースの定義 アクションの定義 AWSサービスの構成 幅広いサービスをサポート スタックイベント履歴 カスタマイズ可能 フレームワーク スタックの作成 スタックの更新 エラー検知とロールバック

デプロイガイド

Quick Start for SAP HANA

CloudFormation テンプレート

{

"AWSTemplateFormatVersion": "2010-09-09", "Description": "(0007) Deploy AWS infrastructure and SAP HANA on AWS",

"Parameters": { "VPCCIDR": {

"Description": "CIDR block for the Amazon VPC to create for SAP HANA deployment",

"Type": "String",

"Default": "10.0.0.0/16",

"AllowedPattern": "[a-zA-Z0-9]+\\..+" },

"HANAInstallMedia": {

"Description": "Full path to Amazon S3 location of SAP HANA

AWSのWebサイトから呼び出すだけ

サーバーとストレージ構成における6つの特徴

OS種類とバージョンが 選択可能 インスタンスタイプには R3とX1から選択、 ノード数が入力可能

EC2 Auto Recoveryの 設定有無が選択可能 データベースファイル用 EBSボリュームのタイプには 汎用SSDとPIOPSが選択可能 データベースファイル用 EBSボリュームの暗号化の 設定有無が選択可能 バックアップ領域用 EBSボリュームは新しい スループット最適化HDD

SAP HANA構成における4つの特徴

ドメイン名、SAP HANAの マスターとワーカーノード のホスト名が入力可能 SAP HANAインストール メディアの格納先はS3 SAP HANAソフトウェアの インストール有無が選択可能 管理用Windowsサーバーの 展開有無が選択可能

1時間未満でSAP HANAを利用可能

Virtual Private Cloud

VPC CIDR (例：10.0.0.0 / 16) プライベートサブネット (例：10.0.1.0 / 24) Availability Zone Amazon S3 SAP HANA インストールメディア バケット Elastic IP Inbound SSH RDP SSH パブリックサブネット (例：10.0.2.0 / 24) Internet gateway Internet バックアップ スナップショット Router 踏み台 VPC NAT gateway SAP HANA (マスター) SAP HANA (ワーカー) Root volume /usr/sap volume HANA data/log volumes Root volume /usr/sap volume HANA data/log volumes HANA backup volume HANA shared volume マスターの NFS共有を マウント RDP (オプション) SAP HANA Studio

設計/構築から運用を網羅したホワイトペーパー

https://aws.amazon.com/jp/sap/whitepapers/ • 料金見積り • サイジング • SAP HANA移行 • 実装と運用 • バックアップ/リカバリー • 高可用性と災害対策

SAP HANA on AWS 4つの移行シナリオ

R3(シングルノード)をX1に変更 複数のR3(マルチノード)をX1に集約 Any DBからX1 or R3へDC/DB移行 AWS外のHANAからX1 or R3へDC移行

X1

X1

X1, R3 X1, R3 R3 R3 R3 R3 R3

本日お伝えしたこと

• X1インスタンスのSAP認定詳細

• すべてのSAPワークロードを、on AWSで

• SAP HANA IaaS Platformsで唯一、

1,952 GiBメモリーのOLAP/OLTP 両方で認定取得

• セントラル構成で131,500 SAPSを達成

• SAP HANA on AWS 構築自動化の仕組み

• Quick Start for SAP HANA(AWS CloudFormation)により 必要な時に、必要なだけSAP HANAを利用可能

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト

辻 正史 2016/6/3

基幹系システムのThe New Normal

～Oracle on AWS～

AWS における Oracle の傾向

Oracle Database は、AWS 上でフルサポート

エンタープライズ用途においても、Oracle Database の ワークロードをアマゾン ウェブ サービス（以下AWS）上 で稼働させることは一般的になっている。

http://www.oracle.com/technetwork/jp/topics/cloud/faq-088380-ja.html#support

２つの Oracle Database on AWS

フルマネージドな Amazon RDS for Oracle Database と セルフマネージドな Oracle Database on Amazon EC2 の2種類が選択可能

Oracle Database on Amazon EC2 Amazon RDS for

Oracle Database

Amazon RDS for Oracle Database

フルマネージドなサービス RDS for Oracle • 数クリックでデータベースが起動 • 運用機能が実装済 • 容易に Multi-AZ 構成を構築可能 サービスとして提供するため、Oracle Database が稼働し ている OS 層を隠ぺいする仕様。

Oracle Database on Amazon EC2

セルフマネージドな Oracle on EC2 環境 • EC2インスタンスにインストール • オンプレミス環境同様の管理 • ファイルベースの移行も可能 オンプレミス環境同様の管理が可能となり、パッケージソ フトウェア等での利用に制限が無い。

本セッションの紹介内容

設計・運用への影響を減らすため Oracle on EC2 を選択 する場合にも、AWS 上で検討すべき項目を紹介 • インストール • ストレージ構成 • バックアップ方式 • 高可用性 • 移行方式

インストーラは OS に設定されているホスト名を認識 インストーラは自動でホスト名を取得し、Oracle Database を構成する設定ファイルにホスト名に依存した 値を設定。

インストーラが認識するホスト名

Hostname listener.ora tnsnames.ora インストーラ

EC2 のホスト名

EC2 のホスト名は自動で設定 EC2 環境では通常、ip-10-0-0-10 等のホスト名が自動で 設定される。 データベースサーバー名を変更したい場合、EC2 ホスト名 の変更が必要。 [ec2-user@ip-10-0-0-10 ~]$ hostname ip-10-0-0-10 [ec2-user@ip-10-0-0-10 ~]$

EC2 のホスト名の変更方法

Red Hat Linux 7 の場合、以下のコマンドでホスト名を固 定化する。

OS 再起動後もホスト名が維持されるように、 /etc/cloud/cloud.cfgに下記の行を追加する。

[root@ip-10-0-0-10 ~]# hostnamectl set-hostname server.domain.company.co.jp --static

インストーラーが認識するホスト名を指定

環境変数 ORACLE_HOSTNAME で指定

明示的にホスト名をインストーラーに認識させる場合、環 境変数 ORACLE_HOSTNAME で指定可能。

ストレージの選択

Oracle Database 専用のボリュームマネージャー ASM を利用

Amazon Elastic Block Store（EBS） を • ファイルシステムとして構築

• Automatic Storage Management（ASM） で管理 の２パターンが考えられるが、ASM の利用を推奨。

DG:SYSTEM

ASM と EBS について

ASM は EBS との組み合わせに適している ASM はブロックデバイス（EBS）を複数束ねて、一つの ディスクグループを構成することが可能。このブロックデ バイスは動的に追加、削除することが可能で、AWS にお いて EBS と相性が良い。 • 容量拡張/縮小 • IO性能向上 ASM DG:DATA

SYSTEM

EBS のボリュームタイプに応じた利用方法

ASM のディスクグループ毎に、EBS のボリュームタイプ を分け Tiered Storage を構成可能 ASM DATA OLD_DATA io1 io1 st1 ディスク グループ EBS ボリューム タイプ io1： 高いIOPSを発揮する 最高パフォーマンスの SSDボリューム st1：高いスループットを発 揮する低コストのHDD ボリューム

EBS 概要

Solid State Drive (SSD) Hard Disk Drive (HDD) ボリュームタイプ プロビジョンド IOPS SSD (io1) 汎用SSD(gp2) 最適化HDD (st1)スループット コールドHDD (sc1) ユースケース I/O性能に依存する NoSQLデータベース やリレーショナル データベース 起動ボリューム、低 レイテンシを要求す るアプリケーション、 開発・テスト環境 ビッグデータ、 DWH、ログデー タ処理 スキャンする頻度が 低いデータ ボリューム毎の 最大IOPS 20,000 (16 KB I/O size) 10,000 (16 KB I/O size) 500 (1 MB I/O size) 250 (1 MB I/O size) ボリューム毎の 最大スループット 320 MB/s 160 MB/s 500 MB/s 250 MB/s 月額料金 (東京リージョン) $0.142/GB+ $0.074/設定IOPS値 $0.12/GB $0.054/GB $0.03/GB

Oracle on EC2 環境のバックアップ

オンラインバックアップには Oracle Recovery Manager（RMAN） が必須 ASM はブロックデバイスをまたいだデータの再配置を行 うことがあり、このタイミングで EBS スナップショット を取得した場合、不整合が発生する可能性がある。 この点からも、RMAN の利用を推奨。

なお、Oracle Secure Backup を利用することで直接 S3 にバックアップを取得可能。

バックアップデータは S3 への格納を推奨

Oracle Secure Backup を利用することで直接 S3 に バックアップ可能 RMAN Oracle Secure Backup ASM Oracle Backup Set S3 EC2

Oracle Secure Backup を利用しない方法

RMAN のバックアップセットをファイルシステムに作成

Oracle Secure Backup は有償オプションのため開発環境 やテスト環境で使用するのは冗長。RMAN の出力先を EBS(st1/sc1)とすることでコスト削減が可能。 RMAN ASM Oracle _EBS Snapshot S3 EC2 RMAN領域

システムバックアップ

製品バイナリおよび ASM は、データと分けてバックアップ Data 製品 バイナリ RMAN領域 構成変更時 定期 S3 ASM ファイル システム ファイルシステム RMAN バックアップ Oracle on EC2

Multi-AZ 構成を意識した高可用性構成

Multi-AZ 構成を採用し、AZ 障害にも対応可能なアーキ テクチャデザインが重要

プロダクション環境で、Multi-AZ を意識する場合、一般 的に Oracle Data Guard が選択肢となる。

Oracle プライマリ Oracle スタンバイ Data Guard _{ライセンスが必要}

Data Guard におけるコスト削減案①

EC2 インスタンスの縮小 スタンバイ側の EC2 を小さくすることで、必要な EC2 コ ストおよび Oracle Database ライセンスの節約が期待で きる。フェイルオーバーが発生した場合は、必要なサイズ の EC2 インスタンスに変更可能。 Oracle プライマリ Oracle スタンバイ Data Guard ライセンスが必要

EBS sc1 スタンバイ側の EBS のコスト削減 スタンバイ側は検索処理が発生せず IOPS も小さくなる。 この場合、コストが低い st1・sc1 の利用も考えられる。 フェイルオーバー時は、io1 に変更可能。 ASM

Data Guard におけるコスト削減案②

Oracle プライマリ Data Guard

Availability Zone A Availability Zone C

Oracle

スタンバイ

ASM

EBS io1

Data Guard を利用しない AZ 障害対策

プライマリ DB の スナップショット から戻す

• テスト、開発環境において Data Guard は過剰 • 定期的なスナップショットから戻す運用

Oracle Oracle

Availability Zone A Availability Zone C

S3 ホスト名を固定していな いと AMI から起動した 際に自動でホスト名が変 更され、正常に動作しな いことが考えられる。

AWS における RAC

(Real Application Cluster） セルフマネージド環境の RAC 構築手順が公開されている。 https://aws.amazon.com/jp/about-aws/whats-new/2015/11/support-for-self-managed-oracle-rac-on-ec2/ あくまで、セルフマネージド環境の RAC であり、開発、 テスト用途に適している。

AWS では RAC が必要なケースは少ない

従来 RAC が解決してきた課題のいくつかはクラウドが解 決済で、この場合 RAC オプションが不要となる。 主な課題 RAC オンプレミス環境 AWS 環境 可用性 ノード障害時にも、稼働ノードで_{即座に処理を再実行可能} 障害時は別H/Wで即時DBを再起動可能 リソース活用 HA構成におけるリソースの無駄を解決 スタンバイのH/Wリソースは不要 拡張性 ノード追加によるキャパシティ増加 必要に応じたインスタンスタイプの変更 ノード障害時、即座に処理の再実行を求められるシステムで RAC は有効。 他の課題は AWS も解決可能で、AWS への移行を視野に検討してみる価 値がある。

移行方式

Oracle on EC2 では、RMAN 等を利用した ファイル ベース の移行が可能

主に以下の方式が利用可能

• Oracle Recovery Manager • Oracle Data Pump

• AWS Database Migration Service • AWS Import/Export Snowball

Oracle Database Standard Edition 2

AWS 上で稼働させる Oracle Database Standard Edition 2 に関するライセンスポリシーが追加 詳細は以下を参照 http://www.oracle.com/us/corporate/pricing/cloud-licensing-070579.pdf Virtual Core については以下を参照 https://aws.amazon.com/jp/ec2/virtualcores/

まとめ

• ホスト名の変更/固定化

• ASM は EBS と相性がよい • バックアップは RMAN

• システムバックアップとデータを個別にバックアップ • Multi-AZ 構成として Data Guard

参考資料

AWS ホワイトペーパー • AWS での Oracle データベースの稼働に関するベストプラクティス https://d0.awsstatic.com/whitepapers/best-practices-for-running-oracle-database-on-aws.pdf • Oracle データベースを AWS に移行するための戦略 https://d0.awsstatic.com/whitepapers/strategies-for-migrating-oracle-database-to-aws.pdf • AWS での Oracle データベースの IOPS のニーズを判別する

https://d0.awsstatic.com/whitepapers/determining-iops-needs-for-oracle-database-on-aws.pdf

• Amazon EC2 で Oracle ワークロード用のオペレーティングシステムを選択する https://d0.awsstatic.com/whitepapers/choosing-os-for-oracle-workloads-on-ec2.pdf • Amazon EC2 の Oracle データベースの高度なアーキテクチャ