今から始めるAWS設計 ～Well-Archなシステムを作ろう～ 2021/10/6 ネクストモード株式会社 吉井 亮

自己紹介 吉井 亮 ネクストモード株式会社 Twitter : @YoshiiRyo1 Blog : https://dev.classmethod.jp/author/yoshii-ryo/ 好きな言葉 : No human labor is no human error.

3 セッション概要 オンプレミスのシステム群をAWSへ移行したい方々、 移行してみたものの本格的な設計まで着手できていない 方々に向けてWell-Archなシステム設計手法を オンプレミスとの違いを交えて解説します。

4 今日話すこと 対象 • オンプレミスのシステム群を AWS へ移行したい方 内容 • AWS をフル活用するアーキテクチャ設計の考え方 • オンプレミスとの違い

5 なぜこの話をするのか ✓ クラウドの利用はまだまだ伸びている ✓ クラウド利用が一般化してきた ✓ 「仮想サーバーの配置変換」だけだと後悔するかも ✓ AWS の良さを十分に活かして欲しい

6 ロールプレイング

7 ロールプレイング 仮想企業を作って AWS 移行を計画してみます。 システムを移行する体でアーキテクチャ設計を 解説していきたいと思います。

8 ロールプレイ 設定 主人公は「未来の世界の猫型ロボット」を 販売する会社の情報システム部員です。 システムのハードウェア保守切れが2年後に迫り 部長から「AWS を使え」と言われています。

9 現行システム Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 Web/AP DB Batch 他システム (移行対象外) F/W Router

10 現行システム • Web/AP は apache&tomcat で構成、 フロントに加え受注/配送管理機能を持つ • DB は MySQL • Batch でリアルタイムや夜間の各種バッチ実行 • 決済プラットフォームとは専用ルーターで接続

11 ゴール Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外) Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS)

12 個別に設計していきましょう

13 AWSの移行戦略 (7R) 移行方式 概要 例 リテイン オンプレミス環境を継続利用 特殊装置や ISDN など クラウドで利用できない理由 リタイア オンプレミス環境のサーバーや アプリケーションを廃止、撤退 使用していないなどの理由 リホスト 仮想サーバーを改修せず単純移行 パッケージ製品を使用している サーバー 既存 DC の契約切れ リロケート 既存サーバーの設置場所を変更 VMware Cloud on AWS リパーチェス アプリケーションの新規購入 SaaS に変更 クラウドライセンスに変更 リプラットフォーム プラットフォームの変更 RDSの採用 Unix から Linux など リファクター クラウドネイティブなアーキテクチャへ 変更 マイクロサービス、 サーバーレスの採用 移行の 複雑さ クラウド化 恩恵

14 7R 今回の例 Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外) Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS) リテイン リホスト リプラット フォーム リファクター リファクター

15 ネットワーク

16 ネットワーク • データセンターとの接続 • 低遅延高品質の Direct Connect を導入 • 低遅延高品質を求めていなければインターネットでも可 (要暗号化) • 高可用性を実現する場合は Site-to-Site VPN を待機系にする • OnP 拠点数が多ければ Direct Connect Gateway • VPC 間接続が多数関係してくれば Transit Gateway

17 サブネット • OnP ではネットワーク境界、トラフィック分離など • AWS ではルートテーブルと NACL を基準にする • 極力フラットに、今回の例では3種類 1. Internet Gateway へのルートを持つサブネット 2. Direct Connect へのルートを持つサブネット 3. VPC 内部ルートのみのサブネット

18 サブネット Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外) Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS) 1. Internet Gateway へのルートを持つサブネット (Public Subnet) 2. Direct Connect へのルートを持つサブネット (To OnP Subnet) 3. VPC 内部ルートのみのサブネット (Private Subnet)

19 CloudFront • CDN • 静的コンテンツをキャッシュして WEB サーバーの負荷減 • DDoS の軽減 • 接続ポイントが多く攻撃を分散する • Lambda@Edge、CloudFront Functions • レンスポンス、リクエストをカスタマイズ

20 WAF • 多層防御の一つ • CloudFront or ALB に紐付けて使う • AWS Managed Rule • セキュリティベンダーのルール • OnP の高性能 F/W を想像すると機能が足りない かもしれないので、要件は細かく掘る

21 コンピュート

22 EC2 • 多くのユーザーが EC2 使っている • EC2 AutoRecovery おすすめ • HW 障害の際に自動再起動して復旧を試みる • CloudEndure や SMS を使うと OnP 稼働中の仮想サーバーをそのままリフト可能

23 EC2 スペック • 大きすぎないインスタンスタイプを選択する • 既存が 4core で 30% しか使ってないなら AWS では 2core でスタートなど • とにかくスモールスタート • インスタンスのスケールアップ＆ダウンは常時検討

24 EC2 スペック • 適切なインスタンスタイプを選択 • ネットワークや EBS 帯域にも気を配る https://aws.amazon.com/jp/ec2/instance-types/ より引用

25 EC2 t2/t3/t4g バースト型の注意 • 安価なため t 系インスタンスを選択 • バースト型の仕組みをよく理解してから使う https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited- mode-concepts.html#how-burstable-performance-instances-unlimited-works より引用 基本的に Baseline までしか CPU 使えない。 クレジットを消費することで Baseline 以上の性能を出す。 クレジット消費量によっては 料金が発生することがある。

26 EC2 と別れを • OS の管理はしたくない • パッチ、ユーザー、ウィルス/マルウェア、ログ、 スケール、冗長化、構成管理、VerUp などなど • EC2 は「ペット」 • 「手がかからない」システムにしたい

27 マイクロサービス化、サーバーレス化しよう

28 コンテナオーケストレーション EKS • フルマネージド Kubernetes クラスター • Kubernetes エコシステムを支える豊富なツール ECS • AWS 提供のフルマネージドコンテナオーケストレー ションサービス

29 コンテナ化は思っているほど難しくはない 動かすだけならそこまで難しくない。 ※本番運用では色々考えないといけません > Dokerfile 例 FROM tomcat:9-jdk8-corretto COPY yourapps.war /usr/local/tomcat/webapps/ COPY server.xml /usr/local/tomcat/conf/ EXPOSE 8009

30 コンテナ化への道のり 1. ローカルの Docker で動いた!!! 2. ECS で動いた 3. Beyond the Twelve-Factor App 参考にしよう 1. https://tanzu.vmware.com/content/blog/beyond-the-twelve-factor-app 4. CI/CD 自動化が楽しい!!! 効率的!!! 5. 社内の矢印をモダンに向けよう

31 データベース

32 ゴール (再掲) Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外) Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS)

33 Relational DB RDBMS on EC2 Aurora,RDS • チーム内に DBA がいる • OnP で培ったノウハウを 活かしたい • ストアドプロシージャを 大量に使って最適化したい • OS 上でコマンド打ちたい • Shared Disk は Single-AZ • DB のことだけ考えたい • 高度な可用性 • AWS マネージド • ストアドプロシージャは 厳しい • DB Version 対応/非対応 VS

34 AWS のデータベース • Relational → Aurora, RDS, Redshift • Key Value → DynamoDB • In-Memory → ElastiCache • Document → DocumentDB • Wide Column → Keyspaces • Graph → Neptune • 時系列 → Timestream • Ledger → QLDB

35 運用

36 運用モデルの再構築 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/fully-separated-operating-model.html より引用

37 運用モデルの再構築 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html より引用 自分で構築して運用する 自分で構築して運用する 差別化につながらない 定常業務は外部委託する SRE的

38 バックアップ • 自動で取得できるものは取得しておく • AWS Backup、RDS ネイティブ、レプリケーション • 何に備えるか？ • 従来より BCP やシステム回復力強化へ

39 監視・通知 AWS 責任共有モデルを理解して監視・通知を行う 「重要ではない通知」に叩き起こされないように • パフォーマンス不安なら AutoScale しておく • 再起動すれば解決する仕組み • AWSステータスも通知対象 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ より引用

40 オペレーション自動化 • チケット起票してオペレーターが実施 • アプリケーションのデプロイ • ログイン出来なくなったWebサーバーの調査 • イベント契機で実施 • git push でデプロイ • HTTP 5xx 多発したら再起動

41 設計上の可用性 AWS サービスごとに設計上の可用性 Single-AZ、Multi-AZ の違いを認識 Control Plane と Data Plane もチェック https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/appendix-a-designed-for-availability-for-select-aws-services.html より引用

42 DR OnP AWS Tokyo Osaka etc Tokyo Osaka 東京リージョンだけでDR要件満たせるケースもある

43 AWS 起因の大規模障害 • オンプレミス、データセンターには無かった事象 • サービスが次々にアップデートされること とのトレードオフ • 想定していない事象が起きる • “きれいにダウンする” ことは少ない（気がする）

44 AWS Well-Architected フレームワーク

45 AWS Well-Architected フレームワーク 設計/実行するための概念、設計原則の ベストプラクティスと質問集。 https://aws.amazon.com/jp/builders-flash/202101/awsgeek-well-architected/?awsf.filter-name=*all より引用

46 弊社ブログにサマリー Well-Architected Frameworkの柱「コスト最適化」を読み解いてみた https://dev.classmethod.jp/cloud/aws/wa-tool-cloud-optimisation-cost/ Well-Architected Frameworkの柱「パフォーマンス効率」を読み解いてみた https://dev.classmethod.jp/cloud/aws/wa-tool-cloud-optimisation-perf/ Well-Architected Frameworkの柱「信頼性」を読み解いてみた https://dev.classmethod.jp/cloud/aws/wa-tool-cloud-optimisation-rel/ Well-Architected Frameworkの柱「セキュリティ」を読み解いてみた https://dev.classmethod.jp/cloud/aws/wa-tool-cloud-optimisation-sec/ Well-Architected Frameworkの柱「運用の優位性」を読み解いてみた https://dev.classmethod.jp/cloud/aws/https-dev-classmethod-jp-cloud-aws-wa-tool-cloud-optimisation-ope/

47 AWS Well-Architected フレームワーク ベストプラクティス（設計原則）は大切。 原則に従えばAWS らしいシステムはできます。 ただ、原則はあくまで原則です。理解をしたうえで 要件を実現させるところで折り合いをつけます。

48 非機能要件チェックリスト https://classmethod.jp/download/cloud-construction-checklist/

49 まとめ

50 まとめ • 移行戦略（７R）から最適な移行方式を選択 • それぞれの特性を理解してAWSサービスを選択 • 設計原則は大切だがあくまで原則 • 要件がまずあるべき • ベストプラクティスが全ての正解ではない

セッション後は、チャット欄のURL、または下記QRコードより アンケートへのご協力をお願いいたします。 SNS投稿にはこちらをお使いください：#devio2021 https://forms.gle/ZhT4ZRuoVzGz77qB8 13:05-13:35 「今から始めるAWS設計 ～Well-Archなシステムを作ろう～」 Q&A Q&A

No content