基幹業務をAWSクラウドで実現する勘所 ～高可用性システム/バックアップのためのアーキテクチャ設計～

Kiyonori Kitasako

Solutions Architect

Wifiは全セッション会場 展示会場にて、ご利用いただけます。

SSID: awssummit #awssummit

自己紹介 • 名前

北迫 清訓

• 所属 アマゾンデータサービスジャパン ソリューション アーキテクト

• 経歴

ハードウェアベンダーにて通信・メディア系のお客様を中心に、システムコンサルから構築、プロジェクトマネージメントを担当

基幹業務システムとは？ • 企業の情報システムのうち、業務内容と直接に関わる販売や在庫管理、財務などを扱うもの。あるいは、単に、業務やサービスの中核となる重要なシステム。

• 扱うデータの大半は定型的なもので、扱う人間も事務員や発注担当者など操作に慣れているものが多いため、複雑なインタフェースや出力の柔軟性よりも安定性と正確さが要求される。

(引用) IT用語辞典 e-Words

システムの安定性

安定性 可用性 (Availability)

稼働率

9 35 days

0.

0

0

0

0

% 9. 4 days

9 9 hours

9 52 mins

9 5 mins

9 32 sec

可用性・稼働率の向上 • インフラレイヤーにおける可用性・稼働率の向上アプローチ

冗長化 予備機への切換を簡素化し、いかにダウンタイムを

短縮させるかがポイント

従来の可用性の考え方

物理から仮想への変革

従来の可用性向上の考え方 • ハードウェアアプローチ

– 筐体の冗長化 – 各種部品の冗長化 – 回線・ネットワーク経路の冗長化

• ソフトウェアアプローチ

– 負荷分散機能によるActive / Active構成 – クラスタ機能によるActive / Standby構成

• データのバックアップ

予備部品の 確保

予備への切換の自動化

保険

従来の可用性向上の考え方

L3 L3

LB (Act) LB (Stb)

AP (Act)

AP (Act)

DB

DB

Storage

Backup

Internet

(Act) (Stb)

物理システムアーキテクチャ構成図

• ネットワークレイヤー – 回線の2重化 – ネットワーク機器の2重化

• Front Endレイヤー – LBの2重化 (Act / Stb) – LBによるAPの負荷分散 (Act / Act)

• Back Endレイヤー – クラスタソフトウェアによる冗長

化 (Act / Stb)

• Backupレイヤー – 大半がシングル構成

• Storageレイヤー – 大型共有ストレージに依存

従来の可用性向上の考え方 • アプローチ

– Single Point of Failure(SPOF)の回避 – 予備機切換の自動化 – 稼働率内での一時的なサービス停止は許容

• その結果

– 予備設備含め管理対象機器が増え、トータル運用コストの増加 – 自動切り替え実装によるシステムの複雑化 – 予備機やり切換部分での障害ポイントの増加 – システム要件とインフラ構成のサービスレベルのミスマッチ

従来の可用性向上の考え方 (技術の進化) • 仮想化によるシステム統合アプローチ

– ミドルウェアの仮想化により、同一環境に複数のアプリをデプロイ – ハイパーバイザーを利用したインフラの共有利用 – サーバ台数の大幅削減 – 仮想レイヤーでのHAの実現 – システム要件とインフラ構成のサービスレベルの柔軟性

冗長化を維持した、 柔軟なインフラ

従来の可用性向上の考え方 (技術の進化)

L3 L3

LB (Act) LB (Stb)

Storage

Internet

VM

AP(Act)

VM

DB(Act)

VM

• ネットワークレイヤー – 物理同様

• Front Endレイヤー – LBの2重化 (Act / Stb) – ハイパーバイザーHA機能で

リソースの有効活用

• Back Endレイヤー – ハイパーバイザーHA機能により

簡易的なHA化も実現可能

仮想システムアーキテクチャ構成図

VM

Backup

• Storageレイヤー – 大型共有ストレージに依存 – ストレージへの依存度増加

• Backupレイヤー – ハイパーバイザーのHA機

能により可用性向上

従来の可用性向上の考え方 (技術の進化)

アプローチ • システムごと別HWに移動させるという新たな冗長性 • 複雑なクラスタ実装からの脱却

進化した結果…. • 仮想化技術により、システムの冗長化に関する考え方の大きな変革 • 可用性に対する選択肢の増加 • ただし、リソースは有限

AWSにおけるの可用性の考え方

AWSによる新たな可能性

AWSにおける可用性向上の考え方 • マネージドサービスの活用

• 予備設備運用からの脱却

• 大量リソースを活用した可用性の実現

• データセンターレベルでの冗長化

不要なコストの削減

冗長構成の シンプル化

複雑な冗長化アーキテクチャをシンプル化 必要なところにリソースやコストを集中

Internet

AWSにおける可用性向上の考え方

AP (Act)

AP (Act)

DB (Act)

Availability Zone Availability Zone

Region

Amazon S3

EBS

ELB (Act) ELB (Act)

Backup

• ネットワークレイヤー – フルマネージド

• Front Endレイヤー – マネージドLB – 冗長化、即座なリソースの切替

え

• Back Endレイヤー – 即座なリソース切換え、SWと

組み合わせたHA化

• Storageレイヤー – インスタンス間のDiskの

付け替え

• Backupレイヤー – マネージドサービスとして

の提供

• データセンター – データセンタレベルでの可

用性

Networkレイヤーでの可用性 • ネットワーク

– フルマネージドネットワーク – 冗長化されたInternet回線 – 内部NWの冗長化

• ハイブリッド環境での冗長化

– 専用線サービス(AWS Direct Connect)での回線冗長化 – VPN接続サービスでのコネクション冗長化 – 専用線およびVPN接続混在型でのルーティングの冗長化

Direct Connect

VPN Connection

X 2

X 2

& Direct Connect VPN Connection

Front Endレイヤーでの可用性 • 負荷分散装置(Load Balancer)

– マネージドLB Amazon Elastic Load Balancing (ELB) • 自動スケールする上、障害を検知すると自動復旧 • マルチAZ構成で、ELB自身も冗長化可能

– LBプロダクトの利用

商用：F5 Big-IP, Citrix NetScaler, Riverbed Stingray etc… OSS：HA Proxy, LVS, mod_proxy_balancer etc..

• プロダクトの冗長化機能の利用 • Amazon Route 53と組み合わせたLBプロダクトの冗長化

ELB

Route53

Front Endレイヤーでの可用性 • Route53を利用したLBプロダクトの冗長化

Amazon Route53 Internet

Availability Zone

Region

Availability Zone

LB LB

EIP EIP

AP AP AP AP

EC2 EC2

Health Check

Routing Policy

死活監視

サービスドメイン名名前解決

生存IPに誘導

SLA100% DNSサービス

Client

Front / Back Endサーバレイヤーでの可用性

• サーバインスタンス – Amazon Elastic Compute Cloud(EC2) インスタンスの

STOP / STARTにより、別HWへの即時移動 – マルチAZ構成で、より高い可用性の実現

• インスタンス障害

– EC2 Status Checkによるインフラレベル障害の自動検知およびオペレーションの自動化

– 監視SWと連動した、システム監視 • Cloudwatch JP1, WebSAM, System Center, Systemwalker

Zabbix, Nagios etc…

Availability Zone

Region

Availability Zone

EC2 EC2 EC2 即時移動

DC越しの冗長化

EC2 CloudWatch SNS

Back Endレイヤーでの可用性 • HAソフトウェアによる冗長化

– 商用：NEC CLUSTER PRO – OSS：Heartbeat, Pacemaker, DRBD etc… – AWS：AWS APIを駆使した冗長化

• ミドルウェア機能による冗長化

– DBプロダクト等のクラスター機能を利用 • MySQL Cluste,r MHA, Oracle DataGuard, SQL Server Replication etc…

• マネージドRDB Amazon Relational Database Service (RDS)

– RDBMSのサービスとインフラ監視、データバックアップを完全自動化 – シングルAZでのインスタンス自動復旧、マルチAZでの自動HAクラスタの構成 RDS

ストレージレイヤーでの可用性 • データ格納ストレージ

– Amazon Elastic Block Store (EBS) • 冗長化されたDisk (Mirroring構成不要) • Software RAIDの併用による冗長性の向上 • インスタンス間でのEBSボリュームの付け替え • Snapshotの利用

Availability Zone

Region

EC2 EC2

付替え EBS EBS

Availability Zone

EC2

Amazon S3 Snapshot

EBS

Restore

バックアップレイヤーでの可用性 • Snapshot

– API, Management Consoleで容易に取得可能 – システムイメージや、EBSボリュームのSnapshot – RDS, Storage GatewayなどのデータボリュームのSnapshot – 同一AZ, マルチAZ, マルチRegion間でのSnapshot共有利用

• Amazon Simple Storage Service (S3)

– SnapshotやAmazon Machine Images格納先 – 物理的に異なる3ヵ所以上のDCへの自動複製により、バックアップデータの外部保管先としての利用

Amazon S3

Amazon S3

AMI EBS RDS

Snapshot

Storage Gateway

データセンタレベルでの可用性 • マルチアベイラビリティーゾーン

– 物理的に異なるデータセンターを活用したシステムの冗長化 – Availability Zone (AZ)間は専用線で接続 – マルチAZに対応した多数のAWSサービス

• EC2, RDS, ELB, VPC, S3 etc…

• マルチリージョン

– 地域(Region)を跨いだ、データセンター間でのシステムの冗長化 – AMI, EBS Snapshot転送によるデータのレプリケーション – Region間はインターネット通信

Region

Availability Zone Availability Zone

AWSによるHAクラスタの実現

HAクラスタをシンプルに

AWSによるHAクラスタの実現

• シングルAZでのクラスター化 – 即時切換 – シンプルな構成 – コストの効率化

• マルチAZでのクラスター化 – データセンターレベルの冗長化 – 比較的高速な切換 – 実装に多少のコツ

シンプルなHA

BCPを実現するHA

AWSによるHAクラスタの実現 • 一般的なHAクラスタの仕組み

1. 障害検知 2. サービスの停止 3. ディスクマウントの切換 4. サービスの再起動 5. 仮想IPの切換

データの受け渡し & 接続ポイントの切換

死活監視

Data Disk

プロセス監視 起動/停止制御

AP Process

死活監視

起動/停止制御 プロセス監視

AP Process

Active機 Standby機

仮想IP切換

Data Disk

Disk接続切換

切換

停止

AWSによるHAクラスタの実現 • AWSでのクラスター化におけるポイント

– 仮想NICのため、複数NICの利用は不要

– 移動用の仮想IPアドレス指定は、ENIとOS両方での指定が必須

– VPCの利用によりIPアドレスの固定化

– EC2インスタンスのSTOP/STARTは同一AZ内での移動

– EBSはAZ毎に存在 • EBSデータのAZ間受け渡しはSnapshot経由

– VPC SubnetはAZでCIDRが異なる • AZ跨ぎのEC2インスタンスの切換はPrivate IPが変わる

シングルAZでのHAクラスタ インスタンスの移動 • インスタンスのSTOP/STARTのみ

• 複雑な切換え実装が不要 • スタンバイ機が不要 • 同一AZ内での切換

Availability Zone

Region

Availability Zone

STOP START

EC2 (Act)

ENI

EBS

EC2 (Stb)

ENI

EBS

VPC Subnet

監視サーバ

監視

切換制御

シングルAZでのHAクラスタ コールドスタンバイ機への切換 • STOP状態のインスタンスにENIとEBSを切換

• AWS APIのみでの実装が可能 • スタンバイ機のコスト削減 • 同一AZ内での切換

Availability Zone

Region

Availability Zone

EC2 (Stb)

EC2 (Act)

ENI

EBS

監視サーバ

監視

切換制御

ENI

VPC Subnet

EBS

Service用

START

シングルAZでのHAクラスタ ホットスタンバイ機への高速切換

• HAクラスタソフトの利用

• 切換の完全自動化 • プロセスやログなどのきめ細かな監視 • 実装のハードルが高い

Availability Zone

Region

EC2 (Act)

ENI

EBS

VPC Subnet

DRBD

Pacemaker Heartbeat

ENI

EBS

DRBD

Pacemaker Heartbeat

EC2 (Stb)

Secondary IP移動 (VIP)

死活監視

データ同期

マルチAZでのHAクラスタ

仮想IPの切換 Private IPアドレスが変更されることへの対応

データの受け渡し AZを跨いだEBSデータの共有

マルチAZでのHAクラスタ

• 内部DNSを利用した接続先Private IPの切換

– AWSに依存せず、実績のある実装 – DNS構築 & 運用が必要

• VPC Subnet Route Tablesの書き換え – AWSの設定のみで実現可能 – 構成が多少複雑化

仮想IPの切換 ~Private IPアドレスが変更されることへの対応~

Availability Zone Region

EC2 (Act)

VPC Subnet

監視サーバ

IP書換え

EC2 (Stb)

VPC Subnet

内部DNSサーバ Front Endサーバ

向き先変更 別IP 別IP

Availability Zone Availability Zone Region

EC2 (Act)

監視サーバ

RouteTables 書換え

EC2 (Stb)

Front Endサーバ

LoopBack IP LoopBack IP

Availability Zone

ENI ENI

LoopBack IPでGWに接続

GW変更

マルチAZでのHAクラスタ

• SWデータレプリケーション機能の利用

– AWSに依存せず、実績のある実装

• EBS Snapshotからの共有

– 切換時にSnapshotを取得 – 切換時のSnapshot時間を短縮するため定

期的な取得が重要

Availability Zone Region

EC2 (Act)

VPC Subnet

EC2 (Stb)

VPC Subnet

Availability Zone

EBS DRBD DRBD

EBS

データ同期

Amazon S3 Snapshot Restore

Availability Zone

Region

EC2 (Act)

VPC Subnet

EC2 (Stb)

VPC Subnet

Availability Zone

EBS EBS

データの受け渡し ~AZを跨いだEBSデータの共有~

AWSによるHAクラスタの実現 • リソースの有効活用し、シンプルな2段構えのHA化

Availability Zone

Region

Availability Zone

Amazon S3 Snapshot

EC2 (Act)

ENI ENI

EBS

VPC Subnet

ENI

Front Endサーバ

監視サーバ

監視

切換制御

Phase2

EC2 (Stb)

EBS

Phase1

STOP/ START

Restore

EC2 (Stb)

EBS START

AMI

Heartbeat

OR

OR

AWSによるバックアップの実現

今日から始めようクラウドバックアップ

AWSによるバックアップの実現 • AWSにおけるデータバックアップの考え方

いかに簡単に Amazon S3へ 格納するか

堅牢性 99.999999999%

3ヵ所以上のDCに自動複製

ファイルの整合性チェック

低コスト

セキュア

AWSによるバックアップの実現

• AWS外のバックアップデータの格納先としてS3を利用

• データの外部保管先としての利用

• 様々なツールを利用してS3に格納

• AWS上のシステムのバックアップデータ格納先としてS3を利用

• Snapshot APIなどのAWS機能をベースにS3に格納

クラウドバックアップ AWSデータバックアップ

AWSによるバックアップの実現

クラウドバックアップ AWSデータバックアップ

Amazon S3

NASアプライアンス

バックアップSW

GWアプライアンス

OSSツール

アップロード RDS Redshift EBS Storage Gateway

EC2(AMI)

Beanstalk CloudFront EMR

Snapshot Log転送 etc..

Amazon Glacier

Archive

Amazon S3へのデータ転送

Amazon S3

EC2

社内NW

アプライアンス製品

クライアントPC

サーバ システム

Internet

専用線(Direct Connect) 1Gbps/10Gbps

Internet VPN

AWS Import/Export パトナー様サービス

Proxy サーバ

Public AS

Private AS

まとめ • 業務システムでの高可用性とバックアップの実現

安定性と正確さ サービス継続ができる仕組みが重要

冗長化 仮想化

HAクラスタ クラウドバックアップ

AWSを活用し • 全てのレイヤーで可用性を高める選択肢を提供 • 適正なコストによる稼働環境からバックアップ環境までを提供 • シンプルなアーキテクチャを採用することでシステムの安定化を図る

Thank You 基幹業務をAWSクラウドで実現する勘所 ～高可用性システム/バックアップのためのアーキテクチャ設計～ Kiyonori Kitasako

Solutions Architect