オンプレインフラエンジニアのための AWS移行の始め方

インフラ勉強会 2019.2.21 資料

Transcript

1. オンプレインフラエンジニアのための AWS移行の始め方 インフラ勉強会 2019.02.21
2. 自己紹介 • JAWS DAYS 2019の個人サポーターです 2
3. 以上！ではあまりにそっけないので… • 名古屋の士業向けWebシステムのインフラのお守りをしてます • 情シス→（兼務）→Webインフラ専業（一応コードも書く人） • SC→名ばかり登録セキスペ（#001158）／NW／DB • 全て40を過ぎてから • 最近は老眼が… • 会計方面では日商簿記2級＋ビジネス会計検定2級 • 簿記3級＋ビジ会2級ぐらいがオススメ 3
4. 内容 • 主にオンプレインフラ（ネットワーク・サーバなど）の構築・管 理をしているインフラエンジニアのうち、 • AWSへの移行に興味がある（or やらざるをえない立場に追い込ま れた）けれどイマイチよくわからない人向けに、 • Webのレガシーなシステム（よくある3層構造というやつ）を例に、 • 移行の流れや注意点などを説明していきます。 • 操作方法等は説明しません • レイヤ0 or 8の話も（あまり）しません 4
5. 今日のゴール • オンプレからAWSへシステムを移行する流れが（なんとなく） イメージできる 　　↓ • AWSコワクナイ 　　↓ • JAWS-UGのイベントに参加したくなる • これが大事！ 5
6. このセッションに向いている人 • 「AWS移行」と聞いて、何から手を付けたらよいかわからない 人 • AWSの膨大な数のサービスの前で立ち尽くしている人 6
7. このセッションに向いていない人 • 自力で進んでいける人 • このセッションの話は無視してください！ • でも、JAWS-UGのイベントには参加してください！ 7
8. 【注意】 • 内容は無保証です • 2年前の移行ケースを元に話を構成しています • すでに事情が変わっている可能性も… • 実際に運用中のシステムを移行される際には、専門家（AWSの 中の人、AWSパートナーなど）のアドバイス・支援を受けるこ とをお勧めします • PoC費用の優遇などのメリットを受けられることもあります 8
9. 【補足情報】 • 登壇者の移行ケースについて、DB観点でまとめた記事がこちら • https://qiita.com/hmatsu47/items/23e2f0b36ab46234b9db • https://qiita.com/hmatsu47/items/a4d98ab9416b5cbdd57b • https://qiita.com/hmatsu47/items/7efe9f267c944d5f7152 • ↑の要約をLTしました（JAWS-UG名古屋支部にて） • https://qiita.com/hmatsu47/items/b0437f0cfb20ee7f0602 9
10. オンプレ→AWS移行に躓く原因と解決法 • AWS用語がわからない • AWSのサービスの概念・特徴がわからない • AWSのサービスが多すぎて全体像が掴めない 　　↓ • 必要な範囲を思い切って絞り込む（広げすぎない！） • 絞り込んだ範囲のAWS用語をおさえる • 絞り込んだ範囲のサービスの特徴をつかむ • 絞り込んだ範囲の検証／PoCを確実に実施する 10
11. オンプレインフラエンジニアなら… • 得意な分野から始めましょう • まずはデータセンターとネットワークから • サーバ寄りのエンジニアのみなさんごめんなさい… 11
12. 主なAWS用語（1/4） • リージョン：地理的に離れた領域 • 東京（ap-northeast-1）、バージニア北部（us-east-1）など • それぞれが独立運用されている • アベイラビリティゾーン：リージョン内のデータセンター（群） • リージョン内に複数ある（大阪ローカルを除く） • リージョンほどではないが地理的に離れている（数キロ～数十キロ程 度） • https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html 12
13. 主なAWS用語（2/4） • VPC（Virtual Private Network）：ユーザがAWS上に構築する仮想LAN • 複数のサブネットに分割できる • VPC間を接続するには何らかのサービスを使う必要がある • EC2（Elastic Computer Cloud）：IaaSのサービス • 仮想マシン • インスタンス：個々のEC2（またはその上で提供されるマネージドサービス） • 複数のインスタンスタイプがある（仮想コア数／メモリ等の組み合わせ） • オンデマンド／スポット／リザーブドインスタンス 13
14. 主なAWS用語（3/4） • マネージドサービス：PaaS（またはSaaS）のサービス • ミドルウェアまたはアプリケーション（と、その組み合わせ）の維持管理ま でAWSが行うサービス • 例）RDS（RDBMSのマネージドサービス）：Oracle、MySQL、PostgreSQLなどの ミドルウェア＋冗長化、バックアップなどをパッケージにしてサービスとし て提供 • S3（Simple Storage Service）：オブジェクトストレージサービス • Route 53：高可用性DNSサービス 14
15. 主なAWS用語（4/4） • IAM（Identity and Access Management）：AWSリソース（サービス等） に対する認証とアクセス制御を提供するサービス • マネジメントコンソール（GUI）、コマンドラインインターフェース（CLI）、 SDK経由の認証とAWSリソースへのアクセス制御 • ポリシー・ロールによるアクセス権の設定 • MFA（多要素認証）など • その他 • サーバレス（Lambda）、オートスケール、… • クラウドデザインパターン、ベストプラクティス、Well-Architected、… 15
16. おさえておきたいAWSの特徴（NWその1） • アベイラビリティゾーン（AZ）間は数キロ以上離れている • AZ内ネットワークの遅延はオンプレと大差ないが（EC2間のRTTが100μs台）、AZ間はや や大きい（同・1ms台） • SLAの提供条件：複数AZでの構成が原則 • 通信制御にはネットワークACL（NACL）とセキュリティグループがある • NACL：サブネットに適用（ステートレス） • セキュリティグループ：インスタンスに適用（ステートフル） • VPCからインターネットアクセスするときの概念が独特 • サブネット（Private、Public）とInternet Gateway、NATインスタンス／NAT Gateway • https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html 16
17. おさえておきたいAWSの特徴（NWその2） • IPアドレスは固定的に運用しないのが基本 • 固定アドレスを割り振ることは可能だがImmutableな運用の妨げになるので注 意 • マルチキャストは使えない • 疑似的に実現することは可能だが、非推奨 • DNSによる名前解決で対象ホスト等を識別するのが基本 • HA構成：仮想IPアドレス等ではなくDNSの正引きIPアドレス入れ替えで実現 • Route 53にはヘルスチェックとの連動や、Aレコードのエイリアス機能がある • キャッシュ用DNSへのアクセスにはI/Fあたりのレートリミットがある • https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-dns.html 17
18. おさえておきたいAWSの特徴（メンテ） • EC2やマネージドサービス基盤のメンテナンス・アップデートがある • 基盤上のEC2やマネージドサービスは無停止の場合もあるが、再起動が必要な 場合もある • アップデートによって性能に大きな影響が出ることも • マネージドサービスのミドルウェアVer.UPは半強制的 • メジャーバージョンはある程度猶予があるが、マイナーバージョンは強制 アップデートとなる猶予が短い • 重要なセキュリティパッチはより強制度が高い 18
19. おさえておきたいAWSの特徴（CLI） • マネジメントコンソール（GUI）でできることはCLIでもできる • リソース（サービス）の初期設定、利用開始、変更、終了など • SDK経由でも同様のことができる • IAMで発行したユーザに権限を付与してアクセスキー／シークレットキーを用 いてCLIやSDK経由の操作をすることができるが、アクセスキー／シークレッ トキーが外部に漏れないよう注意が必要 • できる限りIAMロールを割り当てる方法でリスクを低減 • まずは触ってみて確認！ 19
20. 移行の流れ（1/2） ※大雑把な流れです。 • 企画立案 • 検証／PoC • 移行計画の策定 • 構築 • データ移行（準備） • リハーサル • 移行 20
21. 移行の流れ（2/2） • 移行後の監視→運用開始 • 旧システムの撤去 21
22. 企画立案 • オンプレのシステムをどのようにAWSに移行するのか？ • 移行対象（案） • 移行後の構成・設計（案） • 工程（案） • スケジュール（案） • 予算（案） • ここで詳細を決めるというよりは、検証／PoCに進む上で必要 な事項を仮決めする 22
23. 【注意】 • 最初から欲張りすぎない • サーバレス、オートスケール、… • オンプレの構成を完全に踏襲しようとしない • オンプレと同じ構成ができない・難しい機能もある • 仮に可能だったとしても運用コストが上がる・不安定になることも • 密結合な部分をできるだけ疎結合化できるよう準備しておく • スケジュール・予算はあくまでも概算 • 詳細に決めない • 最初からリザーブドインスタンスをアテにしない • AWSの見積もりはややこしいので専門家の支援を受ける 23
24. 【登壇者のケース】（1/2） • 複数あるうちの、メインのサービスから移行（という案） • 規模感や利用する技術から判断 • 当初はコンテナやサーバレスへの移行はせず、オートスケール もしない（同上。以降も同じ） • アクセスのスパイクが少ない • オートスケール等でのコスト減＜構成を変えるリスク • RDBMSをAurora（またはRDS/MySQL）に移行 • メンバーのスキルレベルを考えるとマネージドサービスへの移行が得 策 • データ保全は最優先（なのでAuroraが第一選択） 24
25. 【登壇者のケース】（2/2） • データは暗号化して保存 • 自社のコントロール下で物理層の作業（ドライブ廃棄等）を行うこと ができないため • 性能面で問題が出ないか？ • ファイアーウォール／UTMの移行に頭を悩ませる→オンプレ踏 襲はしない • オンプレ構成を維持しようとすると将来のスケールの足かせに… • AWS環境では「侵入防止」だけに力を入れるより「侵入検知」「早期発 見」とのバランスを考えて構成するほうが得策と判断 25
26. 検証／PoC • AWS上で移行後のシステムを仮構築 • 実際に動作させて確認し、検証結果をまとめる • 意図したとおりの構成で正しく動作するか？ • 性能は十分か？ • 負荷を掛けたときの性能は？（負荷テスト） • 動作の安定性は？ • フェイルオーバーさせても大丈夫か？ • 加えて、構築手順もまとめる or テンプレート化する • 直ちに問題にならないが後々問題になりそうな点があればメモ 26
27. 【注意】 • 検証時点で運用監視ツールを導入しておく　 • 未導入だとそもそも可否判定が困難 • 検証費用の高額化に気を付ける • 個人アカウントを取って検証／PoCするのはやめましょう… • ためらわずに専門家（AWSの中の人、AWSパートナー）の支援を 受ける • 検証／PoC内容の妥当性についてレビューを受ける • 前述の通り、費用負担のメリットがあることも… 27
28. 【登壇者のケース】 • テストデータを使った小規模な検証では問題なく移行できた • データ暗号化のオーバーヘッドも許容範囲 • しかし、本番データ規模では様々な不具合が発生 • 目標通りの性能が出ない • フェイルオーバーでRDBアクセスの処理が詰まる • いくつかの調整を施して、最低限移行はできる状態に • WebアプリケーションサーバのGC目標時間設定値の調整 • コネクションプーリングのライブラリ変更 • 処理が詰まったときの自動再起動 • 一部は移行後に後追いで実施 28
29. 移行計画の策定 • 検証／PoCの結果をふまえて計画を具体化する • 基本的にはオンプレ→オンプレの移行と変わらない • 但し、スポット的にリソースを確保できるため、リハーサルな ど柔軟に対応しやすい • インフラ構成をテンプレート化しやすいので、その点を考慮に 入れて計画する • AWSのサービスではCloudFormationのスタック／スタックセット • ほかにTerraformなども 29
30. 【注意】 • スケジュール・予算など十分に余裕を見る　 • リザーブドインスタンス導入は運用が軌道に乗ってから考える • リハーサル、撤退ポイントの設定、切り戻し手順を省略しない • AWS移行が初めての場合、オンプレ→オンプレ移行よりもリスクはあるので • 切り戻し判断のための撤退ポイントも決めておくと良い • ためらわずに専門家（AWSの中の人、AWSパートナー）の支援を受け る • 計画に無理なスケジュールや工程がないか指摘してもらう 30
31. 【登壇者のケース】（一部抜粋） 31
32. 構築 • 検証／PoCのときにまとめた構築手順やテンプレートを使って AWS上に移行後のシステム（インフラ部分）を構築する • 場合によっては検証／PoC環境で構築したものをそのまま流用 する • 不要なデータ等の残存に注意（きれいに掃除しておきましょう） • ためらわずに専門家（AWSの中の人、AWSパートナー）の支援を 受ける • （いい加減しつこいかもしれませんが…） 32
33. 【登壇者のケース】 • VPCは検証／PoC環境で構築したものをそのまま流用 • 実は諸事情により検証／PoC環境構築時点からAWSパートナーの支援を 得られず、やむなく • EC2は不要な設定、ログ等をきれいに削除しAMI化して展開 • 諸事情で検証／PoCのときに使っていた運用監視ツールを変更 することに • ここだけAWSパートナーに構築を依頼 33
34. データ移行（準備） • 移行データ容量が大きい場合、サービス停止時間を短くするた め事前にデータ移行の準備をしておく • ファイルのバッチ転送、S3へのコピー • RDBMSのレプリケーション • AWSにもDMS（Database Migration Service）という移行／複製 （レプリケーション）サービスがあるので適宜活用する • 必要に応じて切り戻し用のデータ複製経路／手順を用意してお く 34
35. 【登壇者のケース】 • オンプレファイルサーバ→S3へのバッチ同期（1日数回） • オンプレMySQLサーバ→AuroraのレプリケーションはDMSではな くMySQLレプリケーションを利用 • 慣れた方法で • 一部Auroraの不具合等の影響を受けたがワークアラウンドで対処　 （バイナリログフォーマットの変更、タイムゾーン設定の変更） 35
36. リハーサル • 必ず実施しましょう • 前述の通り、AWSではスポット的にリソースを確保できるため、 構築した新しいプロダクト環境をコピーしてリハーサルに使う ことも簡単 • テンプレートからの復旧確認を兼ねる • 問題点が発覚したら移行作業の工程、スケジュール等を見直す • すぐに解決できそうになければ移行を延期する • 問題解決に向けて専門家（AWSの中の人、AWSパートナー）の支援を受 ける 36
37. 【登壇者のケース】 • リハーサルで使う手順書がなかなか仕上がらず苦戦 • あまり得意でない人が担当せざるを得なかった、という事情が… • リハーサル自体は最低限のラインで実施 • 細かい部分で課題が残った • リハーサル後、移行当日ぎりぎりまで調整が続く • オンプレ環境の機器は相変わらず壊れて週末が修理立ち会いで潰れる など、移行日を延期しようにもできない事情が… 37
38. 移行 • 事前に決めた工程（移行当日の作業手順）通り実施 • Webなどインターネット上に公開するサービスの場合、DNSのレ コード更新でAWS側に切り替え • 基本的にはオンプレDNS（権威サーバ）→Route 53の移行は先に済ませ ておくことになる（Route 53に登録する各Aレコードが指す先はオンプ レ側の旧システムのままで） • 詳細は省略 • 可能な限りメンテナンス停止時間を設けて実施する 38
39. 【登壇者のケース】 • 移行作業そのものはトラブルなく完了 • 但し、やや不安定な気配が… 39
40. 移行後の監視→運用開始 • 移行が完了した後も不具合が発生する可能性があるため、しば らく状態を注視する • 撤退ポイントに相当する大きな問題が発生したら切り戻す • しばらくは新機能のリリース等を控える • 検証／PoC段階で「後々問題になりそうな点」が発見されていた場合、 このタイミングで対処法を探っておくと良いかも • 安定動作が確認できたら平常運用に入る 40
41. 【登壇者のケース】 • 予感は的中し、個々のWebアプリケーションサーバの処理が 度々詰まって再起動する事態に • 但し、サービス提供の継続に大きな支障があるほどの頻度では なかったので、切り戻しはせず • 回避策が見つかり、安定を取り戻すまでに数か月掛かった • その途中にSpectre＆Meltdownパッチによる性能低下が起きて… • 頑張って同僚に休日早朝対応してもらったら、数日後の再パッチでし れっと元の性能に… 41
42. 旧システムの撤去 • オンプレ側の旧システムは忘れずに撤去する • 外部公開サービスは確実に停止する • 特にDNSとMTA • 移行作業の都合で旧システム（オンプレ）用の設定等を新シス テム（AWS）側に施していた場合、忘れずに除去する • 移行作業の際に新システムのDNS（Route 53）に旧システム用のレコー ドを登録していた場合は除去する 42
43. 【登壇者のケース】 • 一部の機能をオンプレ側に残したので、不要になったサーバの 整理にはやや時間が掛かった • ハードウェア自体は1/3程度に規模を縮小 • DRサイトも引き払った • 今年、完全撤去の予定 43
44. まとめ（1/2） • 範囲を絞り込むことが重要 • 移行に必要なAWSの知識・対象サービス • 最初に移行するシステム • 絞り込んだらまずは触ってみるところから始める • とはいえ、現実はなかなか計画通りには進まないもの • 移行を察知してか(?)壊れまくるオンプレ機器たち… • 決められない〇〇（自粛） • というわけで… 44
45. まとめ（2/2） • ためらわずに専門家の支援を受ける • 結果的にコストもリスクも下げる • 早めのコンタクトが大事 • 専門家を知り、仲良くなるために、JAWS-UGに参加しましょう • 「AWS移行の始め方」、答えは↑です！まずはここから！ • AWSパートナー所属の人も、それ以外の強い人もいます • AWSの中の人との接点も多いです • 但し、タダで働かせようとするのはやめてね！ • 専門家以外との交流も！仲間は大事！ 45
46. ありがとうございました