WindowsシステムのAWS移行とMulti-AZ化 - JAWS DAYS 2015

Copyright © 2014 H.I.S. Co., Ltd. All Right Reserved.Copyright © 2015 H.I.S. Co., Ltd. All Right Reserved.
Windowsシステムの
AWS移行とMulti-AZ化
本社情報システム本部
基盤システムグループ
インフラソリューションチーム
チームリーダー榎本貴之

@jawsdays
参加方法は簡単！3ステップ
@awscloud_jp ＋
#jawsdaysをつけてツイート投稿！
1番リツイート数を集めた人が
優勝者です！
AWS公式TwitterとJAWS DAYS公式Twitterをフォロー
??
17:00～の懇親会で優勝者発表です。
※9:00～16:50のTweetが対象です。
＋
Kindle JAWS Tシャツ
＋
ウェアラブル
Moff Band JAWS Tシャツ
Step 1 （参加条件になります）
Step 2
Step 3
（Jaws Daysに関する投稿なら何でもOK！）
JAWS Tシャツ
お知らせ
TwitterでJaws Daysに参加しよう！
たくさんリツイートされた人にプレゼント！

自己紹介
榎本貴之
えのもとたかゆき
本社情報システム本部基盤システムグループ
インフラソリューションチーム
チームリーダー
【好きなAWSサービス】
Direct Connect、CloudFront
【主な業務とか】
サーバやネットワーク、ミドルウェアの導入・運用・管理
比較的得意なのはMicrosoft SQL Serverで、ネットワーク機器が苦手

Agenda
 株式会社エイチ・アイ・エス会社概要
 WindowsシステムのAWS移行とMulti-AZ化
 基本方針
 AWS移行とMulti-AZ化のポイント
 データベース：SQL Server
 ファイル共有：DFS（分散ファイルシステム）
 データセンター内システムとの連携：Direct Connect
 バックアップ：AWS CLI
 まとめ

会社概要
名称株式会社エイチ・アイ・エス（東証1部：会社コード 9603）
登録番号観光庁長官登録旅行業第724号
資本金 11,000百万円（平成27年2月1日現在）
設立昭和55年（1980年）12月19日
本社〒163-6029 東京都新宿区西新宿6-8-1 新宿オークタワー29階
売上高 5,232億円（平成26年10月期連結業績）
従業員数 12,723名（グループ全体平成26年10月31日現在）
加盟・認可団体日本旅行業協会（JATA）、国際航空運送協会（IATA）
主な関連会社
旅行事業テーマパーク事業ホテル事業その他事業

全世界拠点網
世界127都市、186拠点、日本国内303店鋪のネットワーク※
※2015年3月22日現在
●
ヨハネスブルグ
Johannesburg
直近
ＯＰＥＮ
2015/02/02 シアヌークビル（カンボジア）
2015/02/27 クスコツアーデスク（ペルー）
2015/03/09 ジョグジャカルタ（インドネシア）

Agenda
 株式会社エイチ・アイ・エス会社概要
 WindowsシステムのAWS移行とMulti-AZ化
 基本方針
 AWS移行とMulti-AZ化のポイント
 データベース：SQL Server
 ファイル共有：DFS（分散ファイルシステム）
 データセンター内システムとの連携：Direct Connect
 バックアップ：AWS CLI （CLI Tools）
 まとめ

これから話すシステムについて
 現地ツアー（オプショナルツアー）、レンタカーのあたりの話になります
http://activities.his-j.com/
http://restaurant.his-j.com/
http://cars.his-j.com/
http://www.his-j.com/

AWS移行にあたって
 移行のきっかけ
 ハードウェアの保守切れ
 Windows Server 2003のサポート終了
 移行における要件
 ハードウェアの保守期限までに移行を完了させる
 OS（Windows）などのバージョンアップ（最新化）を行う
 メンテナンスコスト等も含めて、全体のコストを下げたい
 オンプレミスで稼働していたときよりサービスレベルが下がるのはNG
 使えるサービスは使うが、
クラウドサービスを使うための無理な改修は行わない
（改修による不具合発生のリスク抑えるため）
 最重要ポイント
 SIerやベンダーに頼らず、自分達で作る
※納期短縮、コスト削減、自社主導

H.I.S. オプショナルツアー/レンタカー on AWS システム概要図
Availability Zone Availability Zone
Remote Desktop
Gateway
WEB/AP WEB/APNAT NAT
Managers
Remote Desktop
Gateway
Batch/ETC Batch/ETCSQL Server SQL ServerDFS DFS
AD-DC AD-DC
AlwaysOn
DFS-R
DFS-N
Managers
Route53 IAM Cloud Watch Cloud Trail
Snapshots
S3
Direct Connect
Elastic Load Balancing
WSFC

WindowsシステムのAWS移行とMulti-AZ化のポイント
 データベース
 SQL Server AlwaysOn on EC2
 ファイル共有
 DFS （分散ファイルシステム）
 データセンター内システムとの連携
 AWS Direct Connect
 バックアップ
 AWS CLI （CLI Tools）

比較：Amazon RDS for SQL Server vs SQL Server on EC2
Amazon RDS for SQL Server SQL Server on EC2
管理 ◎マネージド ×自分で管理
バックアップ ◎自動
△バックアップ時に若干のフリーズ
×自分で管理
○自分で制御可能
メンテナンス
ウィンドウ
△時間指定のみで回避はできない ○自分で管理、制御できる
タイムゾーン △基本的にUTC固定 ○日本時間が選択可能
（EC2のタイムゾーンに依存）
冗長化 ×Single AZ
※2015/3時点でのap-northeast-1
◎AlwaysOnによるMulti-AZ対応
スケールアップ ○可能（SPLAは2xlargeまで） ○可能（ライセンスは別）
スケールアウト ×不可 ○セカンダリをReadonlyで利用可能
ディスクの拡張 ×インスタンス再作成＆データ移行 ○EBS追加で対応
費用 ○RDSの課金 △EC2の課金
×SQL Server EEのライセンス

RDS for SQL Serverについてサポートに聞いてみた
Q.
A.
RDS Single-AZの場合、障害時にどうなりますか？
Multi-AZであれば障害発生に伴いフェイルオーバーが行われますが、 Single-AZの
場合フェイルオーバーができませんので、DBが直ちに影響を受け、アクセ
ス不可もしくはパフォーマンス低下といった状態が予想されます。
RDSへ接続するアプリケーションから通常のDBアクセスを行う
事はできず、アプリケーションとしては接続エラーや、極端な応答速度低下といっ
た形で影響が現れます。
サービス側で復旧が行われるまで、それらの症状は継続しますの
で、DBへ接続する処理については実行不能な状態が続くとお考え
頂ければと思います。
サービス側では可能な限り障害の影響を抑えるべく復旧を行いますが、直ちに復旧
は難しいケースや、場合によっては最後のバックアップ取得以降のデー
タ復旧が難しいケース等も考えられます。
※実際の回答です

SQL Server AlwaysOn on EC2のホワイトペーパー
Implementing Microsoft Windows Server Failover Clustering
and SQL Server AlwaysOn Availability Groups in the AWS Cloud
http://aws.amazon.com/jp/whitepapers/microsoft-wsfc-sql-alwayson/
※構築していた当時より内容が更新されています

SQL Server AlwaysOn on EC2 の作り方（手作り編）
 ステップ０：VPCの構築
 VPCの作成
 Internet Gateway、Route Table、Subnet、NACL等の設定
 セキュリティグループの作成
 ステップ１：Active Directoryの構築
 ドメインコントローラ用のWindowsサーバをLunch
 Active DirectoryとDNSをインストール
 ドメインコントローラに昇格
 ステップ２：Windows Server Failover Clusterの構築
 SQL Server用のWindowsサーバをLunch
 メンバサーバとしてActive Directoryドメインに参加
 Windows Server Failover Clusterの構築
 ステップ３：SQL Server AlwaysOnの構築
 SQL Serverのインストール
 データベースの作成
 AlwaysOn 可用性グループの作成

SQL Server AlwaysOn on EC2 基本事項
SQL Server SQL ServerAD-DC AD-DC
AlwaysOn
 構築手順を全部紹介すると時間が足りないため、ポイントだけお話します
 基本的な事項
 SQL Server とは別にActive Directoryが必要
 Windows Server Failover Clusterが必要
 SQL Serverは2台で、AZを分ける
WSFC
SQL Server AlwaysOn 完成図

Windows Server Failover Clusterの構築の重要ポイント
 SQL Server用のWindows インスタンスに対して
Private IP Addressを3つ設定する
 Lunch時 or Lunch後
プライマリアドレス
WSFC用アドレス
SQL Server用アドレス

SQL Server AlwaysOnの構築の重要ポイント
 SQL Serverを構築するにあたっての超重要事項
 データ、ログ、tempdb、バックアップで、ディスクを分ける
 SQL Serverを実行するユーザに
「メモリ内のページのロック」の権限を付与する
 MAX DOPを設定する
 tempdbのデータファイルをCPUのコア数分作る

SQL Server の設定：MAX DOP（並列処理の最大限度）
 設定値は論理CPUコア数の「4分の1」、
またはNUMAノード上のCPUコア数(ソケット上のCPUコア数)の、
どちらか小さい値
 わからなかったら「1」
 デフォルトはゼロ
 ゼロはダメ、絶対！
※ゼロ＝無制限

Amazon RDS for SQL Server での MAX DOP設定
 Amazon RDSを使う場合も、前述のルールでMAX DOPの設定が必要です！
 設定にはRDSのParameter Groupsを使用
 パラメータ名は「max degree of parallelism」
 RDSのデフォルトは「0」なので注意

Amazon RDS for SQL Server MAX DOPの推奨値
インスタンスタイプ vCPU 推奨MAX DOP
db.m3.medium 1 1
db.m3.large 2 1
db.m3.xlarge 4 1
db.m3.2xlarge 8 2
db.r3.large 2 1
db.r3.xlarge 4 1
db.r3.2xlarge 8 2
db.r3.4xlarge 16 4
db.r3.8xlarge 32 8
db.t2.micro 1 1
db.t2.small 2 1
db.t2.medium 2 1

Amazon RDS for SQL Server をSAPで利用する場合のMAX DOPの推奨値
インスタンスタイプ vCPU 推奨MAX DOP
db.m3.medium 1 1
db.m3.large 2 1
db.m3.xlarge 4 1
db.m3.2xlarge 8 1
db.r3.large 2 1
db.r3.xlarge 4 1
db.r3.2xlarge 8 1
db.r3.4xlarge 16 1
db.r3.8xlarge 32 1
db.t2.micro 1 1
db.t2.small 2 1
db.t2.medium 2 1

RDS for SQL Server が東京リージョンでMulti-AZ対応していない理由
 RDS for SQL Server はミラーリングによってMulti-AZを実現している
 自動フェールオーバーをサポートするミラーリング構成を作るには
3台のSQL Serverが必要。RDS的には3つのSubnetが必要
 3台を別々のSubnet/AZにするには3つのAZが必要
 東京リージョンはAZが実質2つでAZが足りない
Availability Zone A
Availability Zone B
SQL Server
プリンシパル
SQL Server
監視
Availability Zone C
SQL Server
ミラー
Amazon RDS for SQL Server Multi-AZ構成図 ※当人の適当な調べによる推測
クライアント
アプリケーション

Availability Zone
Availability Zone
分散ファイルシステム（DFS）
Windowsファイル共有の仮想化と冗長化
 DFS名前空間（DFS-N）とDFSレプリケーション（DFS-R）を使う
WEB/AP
名前空間サーバ
ファイル共有の実体
（フォルダ・ターゲット）
DFS名前空間
（DFS-N）
クライアント
Datas
DFS
DFS
DFSレプリケーション
（DFS-R）
dfs01
Datas
dfs02
Datas
名前空間サーバを
複数用意して冗長化
フォルダに対して
レプリケートされているフォルダを割り当て
his-j.comShareDatas
名前空間サーバ経由で
実体にアクセス
his-j.comShare
ルートとフォルダを作る
サーバが停止した場合は、
自動的に別のサーバに接続

分散ファイルシステム（DFS）の良し悪し
 メリット
 既存アプリケーションの改修がエンドポイントの変更程度となる
 EC2＋EBSとなるため、基本的にS3よりも高速
 re:Inventでも紹介されている、由緒正しい構成
 デメリット
 Active Directoryが必須
 DFSの管理が必要
 インスタンスが最低２つ必要（コスト高）
 S3のほうが安くて堅牢

オンプレミス（データセンター）にある他システムとの通信
 AWS Direct Connectで万事解決
Amazon VPC
専用線
1Gbps × 2本ルータ
Direct Connect
データセンター
（オンプレミス環境）
相互接続ポイント
Equinix TY2
ルータ
Publicサービス
（VPC外サービス）
AWS
エイチ・アイ・エス Direct Connect 事例： http://www.kvhasia.com/ja/case-studies/h-i-s-co-ltd/

AWS Direct Connect の導入効果
 安心感
 専用線という安心感は何物にも変えがたい
 VPN接続が切れてしまうという不安からの開放
 AWS≒新しいデータセンター
 オンプレミスとまったく同じではない
 従来と考え方が変わり、制約に対して柔軟に対応してゆくことが必要
 EeterpriseでAWSを使う場合、一番最初に使うべきサービスは
Direct Connectだと思う

EC2インスタンスのバックアップ概要
Region: ap-northeast-1 Region: eu-west-1IAM
IAM Role
EC2
EC2 AMI Snapshot
 メンテナンス用のEC2を用意し、バックアップ等のメンテナンスタスクを実行。
該当EC2にはIAM Roleで必要な権限を割り当て。
 バックアップはEC2が作られると、翌日よりAMI（スナップショット）を自動で
取得。登録作業等は不要（とても重要）。
 取得したAMI（スナップショット）を別リージョン（たとえばヨーロッパ等）に
転送することで、データを遠隔地に保管。
IAM Roleを割り当てた
メンテナンス用EC2
EC2インスタンスすべてに
ついて、自動でAMI作成
AMIを別リージョンに転送
ec2-create-image
ec2-copy-image
ec2-describe-instances
AMI Snapshot

EC2インスタンスのバックアップ
 インスタンスIDの一覧取得
 AMI作成
 AMIの削除
 削除するAMIに紐づくSNAPSHOTの情報を取得
 削除するAMIをderegister
 削除するAMIに紐づいていたSNAPSHOTをdelete
ec2-describe-instances --region ${REGION} | grep ^INSTANCE | awk '{print $2}'
ec2-create-image ${INSTANCE_ID} --name ${AMI_NAME} --no-reboot --region ${REGION}
ec2-deregister ${DEL_AMI_ID} --region ${REGION}
ec2-delete-snapshot ${SNAPSHOT_ID} --region ${REGION}
ec2-describe-images ${DEL_AMI_ID} --owner self --region ${REGION}
| grep ^BLOCKDEVICEMAPPING | grep EBS

ec2-create-imageの注意点
 ec2-create-imageは成功しない（失敗する）場合があるので、
結果のチェックが必要
 成功したかどうかはec2-describe-imageしてステータスをチェック
 pending→実行中
 available→成功（完了）
 failed→失敗
 失敗していても、慌てず騒がず、もう１回ec2-create-imageを実行
 原因を追究するのは時間のムダ
ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep pending | wc –l
ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep available | wc –l
ec2-describe-images --owner self --region ap-northeast-1 | grep ÎMAGE | grep failed | wc -l

SQL Server データベースのバックアップ概要
 バックアップ用EBSを用意しBACKUP DATABASEコマンドで
フルバックアップファイルを出力。
その後、バックアップ用EBSのスナップショットを取る。
 トランザクションログもバックアップ用EBSに出力。
回数が多いため、スナップショットではなく個別にS3へ転送。
 古いデータの削除はS3のLifecycleを使う。
SQL Server SQL Server
AlwaysOn
①BACKUP DATABASE
②BACKUP LOG
①バックアップ用EBSの
スナップショットを取る
②LOGは個別にS3へ転送
③Lifecycleで古いデータを削除
バックアップ用
EBS
スナップショット
S3バケットバックアップ用のEBSを追加

SQL Server データベースのバックアップ
 フルバックアップ
 トランザクションログバックアップ
 S3転送
 S3 Lifecycle
BACKUP DATABASE [HISDB] TO DISK = N'D:SQLServerbackuphisdbhisdb_20150322.bak‘
WITH NOFORMAT, NOINIT, NAME = N'hisdb_20150322‘,
SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
BACKUP LOG [HISDB] TO DISK = N'D:SQLServerbackuphisdbhisdb_20150322_0300.trn'
WITH NOFORMAT, NOINIT, NAME = N'hisdb_20150322_0300',
SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10
aws s3 cp D:SQLServerbackuphisdbhisdb_20150322.bak
s3://his-backup/SQLServer/Backup/hisdb/hisdb_20150322.bak

まとめ
Windows環境をAWSに移行しても、特に問題なく稼働中
 良かったこと
 ハードウェアの保守切れが無いので、５年後にリプレースを考えなくて良い
 スケールアップの余地がハードウェアにしばられることがなくなった
 障害時の対応がものすごく楽に（STOP→STARTで完了）
 難しいネットワーク機器の設定が不要
 短期間でのインフラ構築が可能
 タイヘンだったこと
 ap-northeast-1ではRDS for SQL ServerがSingle-AZだった
 AlwaysOnやDFSの構築、検証にそこそこ時間が必要だった
 必要となる運用系のスクリプトは、マニュアル片手にイチから自作した
 障害報告で、理由を完全に説明できず、突っ込まれるとツライ
 それなりにソフトウェアの改修と期間が必要だった
 ソフトウェアライセンス（SQL Server EE）が高額

Thank you !

Windowsシステムの AWS移行とMulti-AZ化 - JAWS DAYS 2015

More Related Content

What's hot

Viewers also liked

Similar to Windowsシステムの AWS移行とMulti-AZ化 - JAWS DAYS 2015