Upgrade to Pro — share decks privately, control downloads, hide ads and more …

今から始めるAWS設計 ~Well-Archなシステムを作ろう~

Ryo Yoshii
October 06, 2021

今から始めるAWS設計 ~Well-Archなシステムを作ろう~

2021年10月5日~14日開催 DevelopersIO 2021 Decade Day 2 ライブセッション「今から始めるAWS設計 ~Well-Archなシステムを作ろう~」の資料を公開します

Ryo Yoshii

October 06, 2021
Tweet

More Decks by Ryo Yoshii

Other Decks in Technology

Transcript

  1. 4 今日話すこと 対象 • オンプレミスのシステム群を AWS へ移行したい方 内容 • AWS

    をフル活用するアーキテクチャ設計の考え方 • オンプレミスとの違い
  2. 10 現行システム • Web/AP は apache&tomcat で構成、 フロントに加え受注/配送管理機能を持つ • DB

    は MySQL • Batch でリアルタイムや夜間の各種バッチ実行 • 決済プラットフォームとは専用ルーターで接続
  3. 11 ゴール Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外) Router

    AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS)
  4. 13 AWSの移行戦略 (7R) 移行方式 概要 例 リテイン オンプレミス環境を継続利用 特殊装置や ISDN

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

    Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS) リテイン リホスト リプラット フォーム リファクター リファクター
  6. 16 ネットワーク • データセンターとの接続 • 低遅延高品質の Direct Connect を導入 •

    低遅延高品質を求めていなければインターネットでも可 (要暗号化) • 高可用性を実現する場合は Site-to-Site VPN を待機系にする • OnP 拠点数が多ければ Direct Connect Gateway • VPC 間接続が多数関係してくれば Transit Gateway
  7. 17 サブネット • OnP ではネットワーク境界、トラフィック分離など • AWS ではルートテーブルと NACL を基準にする

    • 極力フラットに、今回の例では3種類 1. Internet Gateway へのルートを持つサブネット 2. Direct Connect へのルートを持つサブネット 3. VPC 内部ルートのみのサブネット
  8. 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)
  9. 19 CloudFront • CDN • 静的コンテンツをキャッシュして WEB サーバーの負荷減 • DDoS

    の軽減 • 接続ポイントが多く攻撃を分散する • Lambda@Edge、CloudFront Functions • レンスポンス、リクエストをカスタマイズ
  10. 20 WAF • 多層防御の一つ • CloudFront or ALB に紐付けて使う •

    AWS Managed Rule • セキュリティベンダーのルール • OnP の高性能 F/W を想像すると機能が足りない かもしれないので、要件は細かく掘る
  11. 22 EC2 • 多くのユーザーが EC2 使っている • EC2 AutoRecovery おすすめ

    • HW 障害の際に自動再起動して復旧を試みる • CloudEndure や SMS を使うと OnP 稼働中の仮想サーバーをそのままリフト可能
  12. 23 EC2 スペック • 大きすぎないインスタンスタイプを選択する • 既存が 4core で 30%

    しか使ってないなら AWS では 2core でスタートなど • とにかくスモールスタート • インスタンスのスケールアップ&ダウンは常時検討
  13. 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 以上の性能を出す。 クレジット消費量によっては 料金が発生することがある。
  14. 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. 社内の矢印をモダンに向けよう
  15. 32 ゴール (再掲) Customer データセンター キャッシュレス決済 プラットフォーム 製造工場 他システム (移行対象外)

    Router AWS CloudFront Direct Connect Public Subnet Private Subnet To OnP Subnet ALB Aurora Batch (EC2) Front (ECS) 受注 (ECS) 配送 (ECS)
  16. 33 Relational DB RDBMS on EC2 Aurora,RDS • チーム内に DBA

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

    Key Value → DynamoDB • In-Memory → ElastiCache • Document → DocumentDB • Wide Column → Keyspaces • Graph → Neptune • 時系列 → Timestream • Ledger → QLDB
  18. 39 監視・通知 AWS 責任共有モデルを理解して監視・通知を行う 「重要ではない通知」に叩き起こされないように • パフォーマンス不安なら AutoScale しておく •

    再起動すれば解決する仕組み • AWSステータスも通知対象 https://aws.amazon.com/jp/compliance/shared-responsibility-model/ より引用
  19. 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 より引用
  20. 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/