AWS へ全面 Migration するために アマゾンデータサービスジャパン株式会社ソリューションアーキテクトシニアマネージャ 荒木靖宏
ハッシュタグは #AWSRoadshow 皆さんのご意見聞かせてください! 公式 Twitter アカウント @awscloud_jp をフォローすると ロゴ入りコースターをプレゼント コースター配布場所 会場受付
自己紹介 3 名前 荒木靖宏 所属 アマゾンデータサービスジャパン株式会社 技術本部レディネスソリューション部シニアマネージャ 好きな AWS サービス Amazon Virtual Private Cloud AWS Direct Connect 博士 ( 科学 )
AWS への移行メリット コスト高額な先行投資から実需に合わせたオンデマンドな利用へ ハイブリッド自社 DC の拡張としてクラウドを活用段階的移行 用途に合わせた環境選択 ビッグデータ,BCP-DR オンプレミスでは難しい新領域への投資 セキュリティ AWS の優れたセキュリティ環境の利用と自社セキュリティポリシーの適用 4
クラウドネイティブな マネージドサービス も数多く提供 AWS マーケットプレイス エンタープライズアプリケーション プラットフォームサービス セキュリティ & 管理 運用 コア サービス インフラストラクチャー
E-JAWS 調べ どのサービスを使っていますか?(2013 年 11 月 )
企業 IT の AWS 移行を促進した 3 つの特長 仮想プライベートクラウド Amazon VPC 専用線接続サービス Amazon Direct Connect 商用ライセンスの AWS への持込 BYOL(Bring Your Own License)
マイグレーションの流れ 基本はストレート移行 移行のインパクトを下げ 移行コストを低減よりクラウドネイティブな環境へ AWS の各種サービスの利用を検討 研修 保守 現状調査 移行プランの策定 プロジェクト実施 本稼働 テスト 移行対象選定 移行可能性検討 概算見積等 利用ポリシー システム構成 スケジュール 移行考慮点 設計 アプリ移行 基盤構築 テスト 本番移行 8
移行プランの策定 現状調査 移行対象の選定重要度 移行難易度 コスト効果に応じて移行対象を優先度付け アプリ改修の要否 ミドルウェアの対応 システム間連携移行プランの策定 移行考慮点の洗い出し システム構成の検討 クラウドデザインパターンの適用検討 マネージド サービスの活用検討 データ移行 アプリケーション移行方式の検討 セキュリティポリシー / 利用ポリシーの作成 移行スケジュールの策定 システム 重要度 移行難易度 コスト効果 移行 優先度 システム A システム B システム C システム B 9
AWS への移行イメージ 典型的な移行パターン 1.AWS 上に既存環境と同等の OS/ ミドルウェア環境を構築し アプリケーションを移行 2. 仮想 OS イメージを VMImport により移行 データの移行方式は別途検討 Import 元は x86 プラットフォームの一部の仮想化環境 (Windows,Linux) のみとなります 1.AWS 上に OS ミドルウェア環境を新規構築し アプリケーションを移行 アプリケーション アプリケーション アプリケーション アプリケーション ミドルウェア ミドルウェア ミドルウェア ミドルウェア OS 仮想 OS 仮想 OS 仮想 OS 10 既存社内環境 / データセンター 2. 仮想 OS イメージを丸ごと移行 (VMImport)
移行プラン策定のポイント (1/3) OS ミドルウェア 業務パッケージソフト アプリケーション 運用管理の変更点を踏まえた移行方針 方式を検討 ミドルウェアのバージョンアップ等 基本的にはなるべく変更が少ない移行方式が望ましい UNIX システムから移行の場合にはアーキテクチャーの変更にも注意 マイグレーションサービスの利用検討 レイヤー 移行方針の選択によって必要になる対応 C,Java,PHP,Ruby COBOL,Shell Script アプリケーション OSコマンド / メッセージ変更対応 M/W 非互換対応再コンパイル SAP, Oracle EBS, HUE,. Oracle MySQL, Weblogic, Tomcat,. パッケージ / ミドルウェア パラメーター変更 バージョンアップ 運用管理 Solaris, HP-UX, Linux Windows VMware, Hyper-V Unix(SPARC,Itanium) OS / プラットフォーム OS パラメーター変更 バージョンアップ 11 アプリケーションの言語 プラットフォームや OS 変更の有無によっては再コンパイルが必要なケースがあります
移行プラン策定のポイント (2/3) AWS の各種サービスの活用を検討する デプロイメント オートスケーリング RDBMS Elastic Beanstalk DynamoDB AWS OpsWorks KVS キャッシング Amazon RDS ElastiCache イベント ドリブン処理 Auto Scaling 非同期処理 etc, Amazon SNS Amazon SQS Amazon SWF 12
移行プラン策定のポイント (3/3) AWS 利用に関するガイドラインの作成 社内 IT 標準に則した形でクラウド環境に適合した新たなガイドラインを策定 AWS 利用ポリシー AWS 採用システムの範囲の策定 システム重要度の定義と適用技術のマッピング セキュリティポリシー 自社標準ポリシーに合わせた採用技術の選択 AWS アカウント管理のガイドライン策定 etc
既存システムからの移行における検討ポイント 既存のオンプレミスシステムを移行する場合 以下のような点について検討 ネットワーク 仮想サーバの移行 Availability Zone Amazon ELB Web サーバ Amazon EC2 Availability Zone バックアップコンテンツ格納 Amazon S3 バックアップ方式 既存システムとの連携 社内ネットワーク マルチ AZ( マスター ) Amazon RDS Auto Scaling group 参考 オートスケーリングの活用 レプリケーション ブロックストレージ Amazon EBS マルチ AZ( スタンバイ ) Amazon RDS ミドルウェアの稼働条件 ライセンス 14 運用の変更点の考慮 セキュリティポリシー
仮想サーバの移行 VM Import/Export ( 仮想サーバイメージのインポート / エクスポートツール ) VMware/Hyper-V/Citrix Xen の仮想イメージファイルを AWS 上へ移行する為のツール < 対応 OS 一覧 > Windows Server2003/2003R2/2008/2008R2/2012/2012R2 RHEL5.1~6.5 (Redhat Cloud Access を利用 ) Centos 5.1~6.5 Ubuntu12.04, 12.10, 13.04, 13.10 Debian 6.0.0~6.0.8, 7.0.0~7.2.0 http://docs.aws.amazon.com/ja_jp/awsec2/latest/userguide/vmimportprerequisites. html インポート後のインスタンスは 他の EC2 と同じ様に S3 や ELB, Autoscaling などを利用した AWS クラウドの可用性 堅牢性 リソースの柔軟性を享受可能 15
AWS へのデータ移行 データの形式 切り替え時間を考慮し 最適な方式を選択 AWS Database Migration Service の使用フラットファイル データをフラットファイルにダンプアウトし S3 等を活用してデータ移行 DB のレプリケーション オンプレ -AWS 間でデータを同期し 切替時に切断 StorageGateway の活用 オンプレミスのデータをボリューム単位で移行ミドルウェア固有の移行方式 ミドルウェア毎に固有のデータ移行方式を持つものが有る基本はネットワーク経由移行時間はネットワーク帯域に大きく依存 インターネット (VPN) 経由 or Direct Connect の選択パートナーソリューションの活用 DX 環境を利用したデータインポートサービス ( 参考 )http://cloudpack.jp/service/spin-off/directimport.html 16
VM 移行 / データ移行例 (VMImport/StorageGateway) オンプレミス AWS O S O S Manage ment Console /API 端末 VMware SAN 接続 OS イメージ O S vcenter から VMDK ファイルの Export VM DK 共有ディ VM スク DK i-scsi Storage データ Volume vcenter で VMDK ファイルの Import vcenter&os Operation 端末 Storage Gateway Uploa d Buffe r 差分抽出 差分 snapshot Volume 作成 ( 全分 ) 専用線 or VPN VM import API 実行 VMDK Download Internet データの移行 ( データ変更時 ) 差分 snapshot Attach& Mount EBS 作成 ( 全分 ) VM Export API 実行 AWS Endpoint システム環境の移行 ( 環境変更時 ) Launch 17
ミドルウェアの稼働条件 ライセンスの考慮 利用ミドルウェアの稼働条件を確認 ミドルウェアによっては クラウド対応 ( 時間課金 ) のライセンスが適用可能なものもある個別のミドルウェアについてBYOL 対応 時間課金対応 移管方法などの調査が必要ミドルウェアによってはインスタンスタイプが決まっているものもある (SAP 等 ) マーケットプレイスの活用 一部ミドルウェアではミドルウェア導入済みの AMIが提供されている利用料金はAWSから一括請求 https://aws.amazon.com/marketplace 18
ネットワーク構成の検討 (1/2) AWS- 既存 DC 間のネットワーク構成 Direct Connect or VPN 必要帯域や予算 社内ポリシーに応じて選択 DX 複数回線 DX と VPN の併用による冗長構成も可能インターネット接続経路の設計 セキュリティポリシーに応じて設計 VPN 接続専用線 リージョン EC2 VPC 内に分離したサブネットを自由に作成 イントラ VPC プライベートサブネット パブリックサブネット ゲートウェイ Internet VP N DX 19
ネットワーク構成の検討 (2/2) AWS 内のネットワーク構成の決定要素 VPC CIDR / Subnetの設計 Route Tableの設計 Internet Gateway(IGW) の配置検討 Security Groupの設定 Network Access Control List (NACL) の設定 Elastic Network Interfaceの設定 VPC を使用することで AWS 上にオンプレミス同様のネットワーク環境を作り出すことが可能 20
VPC の基本制約 CIDR は大きめに ( サイズ拡張できないため ) L2 延伸は出来ないため 拠点側と VPC は CIDR は重複しないことを推奨 VPC 間は接続可能 ただし CIDR の重複は NG 各 VPC の CIDR は間接的に通信しない場合 CIDR 重複可 172.168.1.0/24 172.168.4.0 Dest : 172.168.4.0 Private ベース Route Table 0.0.0.0 VGW 172.168.3.0/24 EIP Global ベース VPC Peering 172.168.4.0 172.168.4.0/24 172.168.2.0/24 Route Table 0.0.0.0 VGW EIP 21
VPC 設計例 : システムごとに VPC を構築 Subnet( システム A) Subnet( システム B) Subnet( システム共通 ) 利点 システムごとに独立してリソースが管理可能 AWS アカウントを VPC ごとに作成すれば 課金の把握が容易欠点 CIDR ブロックを多く消費するため 事前設計が必要オンプレミスと VPC を直接つなぎたい場合 VPC の数だけ接続をする必要がある 現在は VPC Peering がサポートされているため 本構成が推奨 22
Security Group と NACL(Network Access Control List) AWS では以下のファイヤーウォール機能が提供されている Security Group インスタンスベースのステートフルなファイヤーウォール NACL ネットワークセグメントベースのステートレスなファイヤーウォール Instance レベルで In/Out のアクセス制御 Subnet レベルで In/Out のアクセス制御 各システムにおける通信要件 セキュリティポリシーに応じてそれぞれを適切に設計 設定する 23
各拠点/関連会社既存システムとの連携 VPN or Direct Connectで接続すると 既存システムからプライベートIPアドレスで接続可能 AD 連携 監視連携 データ転送 システム間連携が容易に既存データセンター専用線 SFA 会計 / 人事 給与 各種業務処理 Internet 社内イントラ BI Active Directory ポータル 24 監視システム ファイル共有 Amazon Cloudwatch AWS Management Console
システム連携の留意点 既存システム /AWS 間のネットワークレイテンシー VPN の場合数十 ms~ Direct Connect の場合数 ms~ 例えばオンプレミスの DB に AWS 上の EC2 から頻繁にアクセスするような場合に注意が必要アクセス先 IP アドレス オンプレミスの CIDR ブロック以外でシステム構築するため オンプレミスからの通信先が変わる IP アドレスではなく DNS サーバを使ってホスト名でアクセスする 25
AWS の運用管理のポイント AWS での運用 監視の変更点監視 AWS 以外 (OS 以上 ) のレイヤー 従来通りの監視 AWS が提供するレイヤー Cloudwatch AWS Event 等 AWS が提供する機能を活用運用 基本はセルフサービス AWS 提供機能を活用 ( バックアップ等 ) 自動化には AWS の API を利用 既存の運用管理ツールとの連携 26
AWS 環境での運用 必要な作業 ( お客様の管理範囲 ) システム設計 構築 ネットワークの割り当て ネットワーク構築 システム監視 障害発生時の復旧作業 OSより上の作業 パッチ適用 セキュリティ設定 アプリケーション管理 バックアップ 必要でない作業 (AWS の管理範囲 ) ハードウェア調達 ハードウェアのセットアップ ハード故障時の交換 ハイパーバイザーのメンテナンス Customer 1 Customer 1 Security Groups Hypervisor Virtual Interfaces Customer n Customer n Security Groups 27 Firewall Physical Interfaces 27
運用範囲の変更点 OS より上位レイヤーは既存から変更なし 既存の運用管理の仕組みを流用可能 ソフトウェア ハードウェア レイヤーオンプレ / 仮想化 AWS アプリケーション 変わらない ミドルウェアサーバ管理はRDP/SSH 等でOSへログイン (=オンプレDCとAWSでOS 以上の運用は同じ ) OS 仮想化 ( サーバ ) サーバ+ 仮想化ソフト EC2 仮想化 ( ストレージ ) Storage+ 仮想化ソフト EBS 仮想化 ( ネットワーク ) N/W 機器 + 仮想化ソフト VPC バックアップストレージ 機種ごとの管理が必要 S3 負荷分散装置 機種ごとの管理が必要 ELB ネットワーク (WAN) 不要 Direct Connect 業者に委託 (AWS 側回線の管理は不要 物理ネットワーク (LAN) 機種ごとの管理が必要 不要 物理ストレージ 機種ごとの管理が必要 ネットワーク設計のみ 物理サーバ データセンター 機種ごとの管理が必要 貴社委託先 DC 28 採用技術毎に異なる管理 AWS により標準化された管理
AWS の管理方法 AWS 管理者 オペレータ Management Console (Web) > 各言語ごとの SDK AWS CLI ユーザ名 パスワード REST API アクセスキー シークレットキー EC2 起動 停止 S3 アップロードダウンロード RDS DB 起動バックアップ CloudWatch 情報取得 29
AWS 環境の監視方法 (EC2/EBS/etc...) アプリ性能 / 死活監視 リソース監視 死活監視 ( ログ, プロセス,OS) アプリチェック Agent 経由等の情報収集 CloudWatch/ API/SDK Application Middleware OS Service Status 監視 リソース監視 Event 監視 Alarm 30
AWS 環境の監視方法 ( マネージドサービス ) アプリ性能 / 死活監視 アプリチェック Application CloudWatch/ API/SDK Service Status 監視 リソース監視 Event 監視 Alarm 31
AWS の監視項目一覧 Service Status 監視 (API/SDK/CloudWatch) サービスのステータスを確認 ステータスが正常でない場合は再起動などの対策を実施 Event 監視 (API/SDK) 不定期に発生するメンテナンスに関する情報を取得 関連するサービスに関しては事前に再起動などの対策を実施リソース監視 (CloudWatch/API/SDK) ハイパーバイザーからのリソース情報を取得 使用状況を確認し 必要に応じてリソース量を増減する AWS Service Health Dashboard 確認 Service Health Dashboard でサービスステータスを確認 http://status.aws.amazon.com/ 32
AWS 環境の自動化 AWS に対する全てのオペレーションを API として公開 API コールにより AWS レイヤーの定型処理を自動化可能 Application Middleware OS Managed Services スケジューラ API 33
まとめ
実需に合わせた柔軟なキャパシティ対応 コスト AWS では実際の需要に合わせた柔軟なシステム構成を取る事により投資を最適化 オンとオフ キャパシティ不足 =AWS で適正化 ニーズの増加への対応 過剰なキャパシティ =AWS で削減可能なコスト 予測できないピーク 予測可能なピーク 35 キャパシティの需要オンプレミス環境 AWS 環境
AWS へ移行するメリット オンプレミスと AWS のハイブリッド構成が可能 既存 DC の延長として AWS を利用 既存資産を有効活用 システムの特性に応じて移行可能 移行難易度に応じて移行 コスト効果の高いシステムを移行 更改時期に合わせて移行 クラウド プライベートサブネット プライベートサブネット インターネット プライベートサブネット ハイブリッド 周辺システムから基幹システムへ 既存資産とクラウドを最大活用 プライベートサブネット VPC 社内イントラ VPN APP Web APP APP APP APP APP APP DB DB DB DB SSO DB 専用線 人事 給与 SFA/WF 会計 BI AD 36
ビッグデータ プラットフォームとしての AWS ビッグデータ /BCP DWH ストリーミング等 様々なビッグデータ関連サービスを提供 初期投資不要 低額な従量課金で利用可能 Small Start/Try&Errorが可能 スケーラブルビジネス要件に合わせて必要なだけスケール 37 収集保存解析可視化 Amazon Kinesis 大量データのストリーミング処理 容量無制限のインターネットストレージ Amazon S3 高信頼かつスケーラブルな NoSQL Amazon DynamoDB Amazon RDS フルマネージド RDBMS Amazon EMR フルマネージド Hadoop クラスタ Amazon Redshift ペタバイト級のデータウェアハウス BI Tools or Custom App Amazon EC2 オンデマンドなコンピュートリソース
オンプレミスと同等以上の環境を構築可能 セキュリティ 従来オンプレミス環境と同様にプライベート IP のみで接続外部からのアクセスはネットワークレベルで遮断 東京リージョン 社内 NW ( オンプレ ) Internet VPN Direct Connect Virtual GW EC2 Instance プライベートサブネット EC2 Instance NAT パブリックサブネット EC2 Instance Internet GW 従来と同等のセキュリティ対策 Internet 38
AWS 専用線アクセス体験ラボ sponsored by Intel オンプレミスと AWS との接続を検証してみたい フェイルオーバー時の動作を確認したい スループットがどれだけなのか実際に試してみたい 自前のルータが Direct Connect に接続できるか確認したい などなど http://aws.amazon.com/jp/dx_labo/
AWS プロフェッショナルサービスによるご支援 AWS を利用したシステムのアーキテクチャ設計と実装のご支援 スキルトランスファを行います お客様の計画の様々なフェーズにおいてご支援を提案させていただきます プラットフォーム評価 アセスメント計画 設計開発 適用デプロイメント 本番環境での運用 Current State 戦略計画 ビジネスケース ポートフォリオアセスメント アーキテクチャー 設計アプリケーション開発支援ビッグデータ分析セキュリティ コンプライアンス リスク管理 AWS 環境のエンジニアリング Operatio nal Integrati on New Normal Hybrid IT SIer 様 ISV 様 Managed Service 等の各種サービスとのパートナーシップ 40
サポートについて AWSでは日本語でのサポートを提供 エンタープライズ環境ではビジネス以上を推奨 http://aws.amazon.com/jp/premiumsupport/ AWS サポートは AWS の製品やサービスの開発時および実運用時の問題をカバーするのに加えて 他の主要スタックコンポーネントについても対応します AWS サービスや機能に関する 操作手順 の質問 クラウドでアプリケーションをうまく統合 デプロイ そして管理するためのベストプラクティス API と AWS SDK の問題のトラブルシューティング AWS のリソースに関する操作または体系の問題のトラブルシューティング 当社の Management Console や他の AWS ツールの問題 健全性チェックで検出された問題 多数のサードパーティ製アプリケーション ( 例 : OS ウェブサーバー E メール データベース ストレージ構成 ) 41 ベーシックデベロッパービジネスエンタープライズ サポートフォーラム利用可能利用可能利用可能利用可能 サポートへのコンタクト 最速初回応答時間 EC2 の健全性エラーが発生した場合 不可 コンタクトフォーム 12 時間以内 ( 営業時間内 ) 電話 チャット コンタクトフォーム 電話 チャット コンタクトフォーム 1 時間以内 15 分以内 連絡先登録 1 5 無制限 24/365 対応なしなしありあり 上級サポートエンジニアへの直接ルーティング なしなしありあり 専任スタッフなしなしなしあり 特別サポートなしなしなしあり 料金 ( 月額 ) 無料 4,900 円 AWS 利用総額の 0 円 ~120 万円 : 10% 120 万円 ~840 万円 : 7% 840 万円 ~3,000 万円 : 5% 3,000 万円 ~ 3% ( 最低 12,000 円 ) 1 ドル 120 円換算 AWS 利用総額の 0 円 ~1,800 万 : 10% 1,800 万 ~6,000 万 : 7% 6,000 万 ~12,000 万 : 5% 12,000 万 ~ 3% ( 最低 150 万円 )
エンタープライズサポートご支援体制 Enterprise サポートご契約のお客様 技術的な問題解決支援やエスカレーション窓口 ソリューションアーキテクト テクニカルアカウントマネージャー (TAM) 専任のエキスパートによる対応 サポートエンジニア 構成や設計方針への支援 アカウントマネージャー 個々のお問い合わせ対応 アカウント ご利用料金関連 (+ 全般 ) のサポート 42
Thank You