第1回 AWS勉強会 AWSの歴史, AWS Well-Architected Framework 笹川 尋翔 

AWS何も分からん⼈に3⾏で • 有名なクラウドコンピューティングサービス • 正式名称は “Amazon Web Services” • 柔軟性が⾼いシステムを簡単に低コストで構築できる アマゾンウェブサービス icon by Icons8 

AWSの⻑所 • 規模の経済(後述)によってリソースを低コストで利⽤できる • 柔軟性が⾼いシステムを簡単に構築できる • 開発のアジリティ(機敏性)を向上させる • システムを素早くグローバルにデプロイ(展開)できる • 責任共有モデル(後述)に基づくシステム管理コストの低減 • AWSサポートによる⼿厚いサポートを受けられる https://aws.amazon.com/jp/aws-ten-reasons/ 

規模の経済(economic of scale) • ⽣産規模を⾼めることで単位当たりのコストが低減される • 固定費と変動費を考慮するとたくさん⽣産すればするほど コストパフォーマンスが⾼くなる https://www.axc.ne.jp/preparations/glossary/economic_of_scale.html 

責任共有モデル • AWSが責任を負う部分とAWSの顧客が責任を負う部分を分ける考え⽅ • AWS • ハードウェアやデータセンターを管理する責任を負う • AWSの顧客 • OSのパッチ適⽤、アクセス制御、システムの顧客のデータ保護などの責任を負う https://aws.amazon.com/jp/compliance/shared-responsibility-model/ 

オンプレミスとクラウド • オンプレミス • 物理サーバなどを⾃社で保有して運⽤ • ハードウェアの導⼊・管理コストが⾼い • ハードウェアの導⼊までに数週間掛かる • クラウド • クラウドサービスを利⽤して物理サーバなどを使⽤ • ハードウェアの導⼊・管理コストが低い • ハードウェアをわずか数分で導⼊できる 

オンプレミスとクラウド • 2018年時点で、オンプレミス環境を運⽤している企業の40% 以上がオンプレミスからクラウドへ移⾏したいと考えている • ⼤規模なシステム開発では、クラウドへの移⾏でコストを⼤幅 に削減できる https://japan.zdnet.com/article/35120911/ 

AWSの歴史 - 登場したサービス - • 2004年 • Amazon SQS(Simple Queue Service)を発表 • 2006年 • Amazon S3(Simple Storage Service)を発表 • Amazon EC2(Elastic Compute Cloud)を発表 • 2008年 • Amazon CloudFrontを発表 https://aws.amazon.com/jp/blogs/aws/aws-blog-the-first-five-years/ 

AWSの歴史 - AmazonとAWS - • 2000年 • Amazon.comのインフラストラクチャをSun MicrosystemsサーバからLinux サーバへ移⾏するプロジェクトを開始 • およそ1年間掛けてLinuxサーバへの移⾏を完了 • 組織の柔軟性を確保するためにアーキテクチャの疎結合化を進める • サーバの余剰リソースが⼤量に存在することに気付く https://www.publickey1.jp/blog/21/awsamazonsunhplinux.html 

AWSの歴史 - AmazonとAWS - • 疎結合なシステムを活⽤してITリソースを貸し出せないか？ • “クラウド”という概念が誕⽣ • ITの起業コストを⼤きく削減 

AWSが学んだこと • AWS⾃⾝が様々なベストプラクティスを学んだ • 単⼀障害点(SPOF)を無くす • 疎結合アーキテクチャを設計する • セキュリティを常に最優先に • ⽔平⽅向にスケール • システムに弾⼒性を持たせる https://dev.classmethod.jp/articles/old-aws-architecture-best-practice/ 

AWS Well-Architected Frameworkの誕⽣ • 2015年にAWS Well-Architected Frameworkを公開 • AWSのベストプラクティスをまとめたもの • 現在は6つの柱で構成される • オペレーショナルエクセレンス(運⽤上の優秀性)の柱 • セキュリティの柱 • 信頼性の柱 • パフォーマンス効率の柱 • コスト最適化の柱 • サステナビリティ(持続可能性)の柱 https://aws.amazon.com/jp/architecture/well-architected/ 

⼀般的な設計の原則 • キャパシティニーズを推測しなくていい • オンプレミスのように必要なキャパシティを考える必要がない • 本番環境と同等のテスト環境でテストする • オンデマンドインスタンスを利⽤して低コストで本番環境を シミュレート • システム構築・運⽤を⾃動化する • コストダウン、⼿作業による負担を軽減 https://dev.classmethod.jp/articles/aws-well-architected-guide2022/ 

⼀般的な設計の原則 • アーキテクチャを必要に応じて進化させる • 例) ユーザ数の増加に伴いモノリスからマイクロに • アーキテクチャをデータドリブンで改善 • システムのデータを収集 → 事実に基づいて意思決定 • ゲームデーを利⽤して改善 

ゲームデー？ • エンジニアが息抜きのためにゲームを する • テスト環境でわざと障害を発⽣させる • 障害対応の⼿順を確認 • 障害からの復旧を⾼速化 

オペレーショナルエクセレンスの柱 • ワークロードをコードとして定義 • IaC(Infrastructure as Code)ツールでワークロードを管理 • 例) Terraform, CloudFormation • ⼩規模で可逆的な変更を頻繁に⾏う • 有益な変更を取り⼊れやすくする 

オペレーショナルエクセレンスの柱 • 運⽤⼿順を頻繁に改善 • ワークロードを変更する際に運⽤⼿順を改良する • 障害を予想する • プレモータム演習(潜在的な障害の原因を特定すること)を実施して障害の影 響を算出し、障害が起きる前にその原因を排除 • これまで起きた障害から学んだ教訓を組織全体で共有 • アーキテクチャ設計やシステム運⽤⼿順を改善 

セキュリティの柱 • 強⼒なアイデンティティ基盤を実装 • 最⼩権限の原則を導⼊して 適切な権限を与える • アクセスキーを定期的にローテーション(更新)する • トレーサビリティ(追跡可能性)を実現する • ログとメトリクスをリアルタイムで⾃動的に収集 • 脅威があるかどうかを⾃動的に調査 • 調査結果に基づいて⾃動的にアクションを実⾏ • 全てのレイヤーでセキュリティ対策を⾏う • VPC, インスタンス, OS, アプリケーションなど 

セキュリティの柱 • 伝送中や保管中のデータを保護する • AWS KMS(Key Management Service)などを利⽤してデータを暗号化 • データベースやストレージの暗号化 • データに対する処理を⾃動化する • ヒューマンエラーのリスクを軽減 https://aws.amazon.com/jp/kms/ 

信頼性の柱 • 障害から⾃動的に復旧する • Auto ScalingやRoute 53などを利⽤ • ⽔平⽅向にスケールして可⽤性を⾼める • 単⼀の⼤規模なリソースを複数の⼩規模なリソースに置き換える • キャパシティの推測をやめる • 需要に応じて⾃動的にキャパシティを調整する仕組みを導⼊する 

パフォーマンス効率の柱 • テクノロジーをサービスとして利⽤する • 例) EC2インスタンス上にDBサーバを配置して⾃分で管理するよりも RDSなどのマネージドサービスを利⽤して管理コストを削減 • 数分でグローバルにデプロイ • 現在27あるAWSリージョンを活⽤ • 世界中の顧客に最⼩限のコストでシステムを提供 • サーバーレスアーキテクチャを使⽤ • 物理サーバの運⽤コストを無くす • スケーラブルなシステムに 

サーバーレスアーキテクチャ • AWS Lambda • HTTP経由でAPIにアクセス • 代表例) AWS LambdaとAmazon API Gatewayを利⽤した REST APIアプリケーション • Amazon API Gateway • APIの作成・管理 

コスト最適化の柱 • クラウドで財務管理を⾏う • ビジネス価値の実現のために必要な投資を⾏い、コスト効率を向上させる • 必要な分だけコンピューティングリソースを使う • オンデマンドインスタンスなどは1秒単位で課⾦される • インスタンスは使うときだけ開始し、不要なときは停⽌する • ビジネス価値の差別化に繋がらない作業のコストを無くす • ハードウェアの保守は責任共有モデルに基づいてAWSが実施 • マネージドサービスを利⽤して運⽤上の負担を解消 

コスト最適化の柱 • サービスごとの費⽤などを明らかにする • Cost Explorer, Budgets, Billing Consoleを利⽤ • 費⽤とリソースの使⽤量を正確に特定 

サステナビリティの柱 • リソースの利⽤率を最⼤化する • 需要に応じて動的なスケーリングを⾏うアーキテクチャを設計 • 余剰リソースが発⽣しないようにする • 例) CPU使⽤率が10%になるインスタンスよりも、 CPU使⽤率が50%になるインスタンスを使う • より効率的な製品を採⽤する • 例) t2.microよりもt3.microやt4g.microを採⽤する • マネージドサービスを利⽤する • サステナビリティのベストプラクティスを⾃動化