2023エンジニア定例 AWS基礎 

自己紹介 渡邊　大介 入社　　　2019年4月 担当業務　自社WEBサービスの運用開発 趣味　　　映画、ドライブ、バドミントン 

自己紹介 宮本　達矢 入社　　　2020年4月 担当業務　自社WEBサービスの運用開発 趣味　　　読書 

アジェンダ 1. クラウドについて 2. クラウドサービスの違い（SaaS,IaaS,PaaS） 3. AWSについて 4. AWS Well-Architectedについて 5. ハンズオン（スケーラブルウェブサイト構築） 6. ハンズオン（サーバーレスアーキテクチャ構築） 7. アーキテクチャ図 8. コスト意識 

クラウドについて 

クラウドとは？ ● クラウド（クラウドコンピューティング）とは、インターネットを通じてリソース やサービスを提供する仕組みのことを指す ● 従来のコンピューターシステムでは、自社内部でサーバーやソフトウェアを保有・ 管理する必要がありましたが、クラウドでは必要なリソースやアプリケーションを インターネット上のサービスプロバイダーから利用することができる 

なぜクラウド（雲）と呼ばれるのか？ ● インターネット上のリソースやサービスがユーザーにとって不可視であり、まるで 雲（Cloud）のように存在しているかのように表現することからきている ● クラウドは複数の場所に分散したリソースやサービスがインターネットを通じて提 供される仕組みを指しており、そのイメージから「クラウド」と呼ばれるように なったと言われている 

クラウドの対義語 ● クラウドの対義語はオンプレミス ● オンプレミスとは、全てのハードウェアとソフトウェアを組織が所有し、専門のス タッフが運用・保守を担当する ● データのセキュリティや管理に対する直接的なコントロールがあるが、設備の維持 ・更新にかかるコストやリソースの効率的な利用が課題となることもある 

クラウドサービスの違い（SaaS,IaaS,PaaS） 

クラウドサービス ● クラウドサービスを深ぼっていくとSaaS,IaaS,PaaSという言葉を聞くことが多くなる ● これら3つのサービスの違いと責任範囲について説明していきます 

Software as a Service（SaaS） ● ソフトウェアはクラウド上のサーバーで実行され、ユーザーはウェブブラウザを介してインター ネット経由でアクセス ● 企業や個人にとって柔軟性、コスト削減、メンテナンスの負担軽減などの利点をもたらす ● データ以外の管理はすべてクラウド事業者に責任がある 

Platform as a Service (PaaS) ● ハードウェアやネットワークインフラストラクチャ、オペレーティングシステムなどの基盤を提 供し、開発者はこの基盤上でアプリケーションを作成・実行することができる ● データ、アプリケーション以外の管理はクラウド事業者が行ってくれるので、アプリケーション 開発に注力できる 

Infrastructure as a Service (IaaS) ● 基盤となるインフラストラクチャが仮想化され、ネットワーク、ストレージ、仮想マシンなどの リソースを利用することができる ● ユーザーはこれらのリソースを自由に構成し、オンデマンドで利用することができる ● ハードウェア以外の管理はユーザーに委ねられているため、責任範囲は大きいが柔軟なサービス を構築することができる 

AWSとは 

AWSとは ● AWSは、Amazon Web Servicesの略で、Amazonが提供する クラウドコンピューティングサービスの総称 ● 2006年に、Amazon 社内のビジネス課題を解決するために 生まれた IT インフラストラクチャのノウハウをもとにサー ビスがスタート ○ 詳しい背景はこちら ● クラウドインフラサービスにおけるAWSの市場シェアは約 33％で世界一位 https://techcrunch.com/2023/02/06/even-as-cloud-infrastructure-m arket-growth-slows-microsoft-continues-to-gain-on-amazon/ 

200を超える幅広いサービスを提供 https://aws.amazon.com/jp/aws-ten-reasons/ 

データセンター ● 全世界31の地域にデータセンターを置い ている ● 日本国内には関東と関西に複数のデータ センターが存在している 

リージョン ● リージョンとは、AWSが運用するデータセンターがある地域のことを指す ● 各リージョンは、独自のインフラストラクチャとネットワークを持っており、それぞれ異 なる地理的な場所に配置されている ● 日本のリージョンは以下のように表される ○ ap-northeast-1（アジアパシフィック (東京)） ○ ap-northeast-3（アジアパシフィック (大阪)） https://aws.amazon.com/jp/about-aws/global-infrastructure/ 

アベイラビリティゾーン（AZ） ● 各リージョンには複数のアベイラビリティーゾーン （AZ）が存在している ● AZは物理的に分離されたデータセンターのグループ である ● 各AZは高可用性と耐久性を確保するために設計され ている https://www.techtarget.com/searchcloudcomputing/tip/Understan d-AWS-Regions-vs-Availability-Zones 

AWS Well-Architected 

AWS Well-Architectedとは ● AWSサービスの活用を支援するために2015年に発表されたもので、6つの柱で構成され 毎年更新が行われている ● AWS内に蓄積されたシステム構築に関するベストプラクティス集であり、AWSでシステ ムを構築する際に、選択肢の⻑所と短所を理解できるようになっている 

オペレーショナルエクセレンスの柱（運用上の優秀性） ● AWSシステムが正しく運用され、維持されるために必要な様々な要素について、どのように実施 すれば最も効果的かを示したもの ● ログ管理やモニタリング、運用自動化、セキュリティなど、運用に関連する重要な項目が含まれ る ● システムの信頼性や可用性、セキュリティが向上し、システム管理者がより迅速かつ正確に問題 を解決できるようになる 実装ガイド https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html 

セキュリティの柱 ● AWSシステムがセキュリティ上の脅威から守られ、顧客のデータが安全であるために必要な様々な 要素について、どのように実施すれば最も効果的かを示したもの ● アクセス管理、データ暗号化など、セキュリティに関連する重要な項目が含まれる ● システムの信頼性や可用性、顧客データのセキュリティが向上し、セキュリティ上の問題を未然に 防止することがきるようになる 実装ガイド https://docs.aws.amazon.com/ja_ jp/wellarchitected/latest/security-pillar/welcome.html 

信頼性の柱 ● AWSシステムが正しく稼働し、予期せぬ障害が発生した場合でも、システムが迅速かつ自動的に回 復するために必要な様々な要素について、どのように実施すれば最も効果的かを示したもの ● マルチAZの活用、冗長性の確保、負荷テスト、エラー処理、モニタリングなど、信頼性に関連する 重要な項目が含まれる 実装ガイド https://docs.aws.amazon.com/ja_ jp/wellarchitected/latest/reliability-pillar/welcome.html 

パフォーマンス効率の柱 ● AWSシステムが必要なパフォーマンスを提供するために必要な要素について、どのように実施すれ ば最も効果的かを示したもの ● 要件に応じて最適化されたリソースタイプやサイズの選択、パフォーマンスのモニタリング、ビジ ネスニーズの増大に応じて効率を維持することが含まれる 実装ガイド https://docs.aws.amazon.com/ja_ jp/wellarchitected/latest/performance-efficiency-pillar/welc ome.html 

コスト最適化の柱 ● AWSシステムが必要なリソースを最小限に抑え、コストを最適化するために必要な要素について、 どのように実施すれば最も効果的かを示したもの ● リザーブドインスタンスの活用、インスタンスサイズの最適化、ストレージの最適化、使用量のモ ニタリングなど、コスト最適化に関連する重要な項目が含まれる 実装ガイド https://docs.aws.amazon.com/ja_ jp/wellarchitected/latest/cost-optimization-pillar/welcome.html 

持続可能性の柱 ● 6年ぶりに追加された6本目の柱 ● 最近話題のサステナビリティへの取り組みの話 ● 実行中のクラウドワークロードによる環境への影響を最小限に抑えることに重点を置いている ● 持続可能性の責任共有モデル、影響の把握、リソースの最小化、使用率の最大化が含まれている。 これらの取り組みによって、ダウンストリームの影響を減らすことができる 実装ガイド https://docs.aws.amazon.com/ja_ jp/wellarchitected/latest/sustainability-pillar/sustainability- pillar.html 

ハンズオン（スケーラブルウェブサイト構築） 

スケーラブルウェブサイト構築 https://pages.awscloud.com/JAPAN-event-OE-H ands-on-for-Beginners-Scalable-2022-reg-event. html?trk=aws_introduction_page ● AWS公式のハンズオンをもとにWordPressを用いたス ケーラブルなブログサービスの構築を行う 

ハンズオン（サーバーレスアーキテクチャ構築） 

サーバーレスアーキテクチャ構築 ● AWS公式のハンズオンをもとにサーバーレスアーキ テクチャを用いて翻訳Web APIを構築する https://pages.awscloud.com/JAPAN-event-OE-Han ds-on-for-Beginners-Serverless-1-2022-reg-event.h tml?trk=aws_introduction_page 

アーキテクチャ図 

突然ですが、 どっちがわかりやすいですか？ 

１ ● ユーザはAmazon CloudFrontを通してアクセスする ● Amazon CloudFrontのオリジンにはAmazon API GatewayとAmazon S3を 設定している ● Amazon S3には静的サイトで利用するファイルが入っている ● Amazon API GatewayにはAWS Lambdaが紐づいている ● AWS LambdaからはAmazon RDS Proxyを通してAmazon RDSに接続して ユーザデータを取得する 

2 

構成は同じでも、文章で書いてある方は すぐに頭に入ってこない 

アーキテクチャ図とは ● 頻繁に目にする上のような図をアーキテクチャ図と呼ぶ 

アーキテクチャ図がないと何が不便なのか ● システムのアーキテクチャを一目で認識することができない ○ 文章で構成を表すことも不可能ではないが、認知負荷は図示された場合と 比べ物にならない ○ 文章すらなければ、実際のリソース一つ一つを確認することでしか 確かめることができない ■ 複雑であればあるほど把握し辛くなる ● 同じシステムを担当するチーム内でも理解度に差が生じやすい ○ あまり触れないリソースは存在自体を知らないということも ■ アーキテクチャ図があれば、最低限存在だけは把握できる ○ システム担当者でも理解しづらいので、それ以外の人は言わずもがな 

アーキテクチャ図をどう描けばいいか？ ● アーキテクチャ図の書き方がわからない方におすすめの記事 ○ https://aws.amazon.com/jp/builders-flash/202204/way-to-draw-arc hitecture/ ● アーキテクチャ図に正解はない！と上記の記事でも言われている ● とりあえず見よう見まねで書いてみる ● 他のシステムのアーキテクチャ図を眺めて良さそうな部分を真似していく 

コスト意識 

クラウドにはお金がかかる ● クラウドでは利用した分だけお金がかかる ○ 不要なコストを削減することで会社の利益UPに繋がる ○ 知らずに使いすぎるととんでもない請求になるかもしれない ● クラウドを利用する上で、コスト意識は必ず持つ必要がある ○ コスト予測: やろうとしていることにどれだけコストが掛かりそうか ○ コスト把握: 現在稼働しているものにどれだけコストが掛かっているか 

サービスごとのコスト ● 各種クラウドのサービスごとの利用料金は公式ドキュメントに記述がある ○ AWS ■ AWS Lambda: https://aws.amazon.com/jp/lambda/pricing/ ■ Amazon S3: https://aws.amazon.com/jp/s3/pricing/ ○ GCP ■ Cloud Functions: https://cloud.google.com/functions/pricing?hl=ja ■ Cloud Storage: https://cloud.google.com/storage/pricing?hl=ja ● 個々のサービスのコストを確認することはできるが、複数のサービスを利用した システムを作成する場合にこのページだけを見てコスト計算するのは手間…… ○ 専用の料金計算ツールが用意されている 

コスト予測: AWS Pricing Calculator ● AWSの複数のサービスを組み合わせた コスト見積もりを作成するツール ● 利用したいサービスを選択し サービスごとの料金計算に必要な要素を 入力することでコストの計算が可能 ● 計算結果から共有URLを生成して 結果のシェアが容易に可能 AWS Pricing Calculator: https://calculator.aws/#/ 

コスト計算の例: Amazon CloudFront + Amazon S3構成の静的サイト+API Amazon CloudFront+Amazon S3構成、ページ表示時に Amazon RDSに保存されたデータを取得し表示しているサイト 

● AWS Lambda ○ アクセス数: 1000アクセス/時間 ○ 平均処理時間: 100ms ○ CPU: 128MB ○ メモリ: 512MB ● Amazon RDS ○ ノード数: 1 ○ インスタンスタイプ: db.t3.medium ○ 稼働率: 100% コスト計算の例: Amazon CloudFront + Amazon S3構成の静的サイト+API 見積もり条件 ● Amazon CloudFront ○ リクエスト数: 17280000リクエスト/月 ■ 1アクセスあたりのリクエスト数: 24 ● html, js, css, 画像20種類+APIアクセス ■ 1000アクセス/時間 * 24時間 * 30日 * 24リクエスト/アクセス ○ データ転送量（インターネット）: 21TB ■ =1000リクエスト/時間 * 24時間 * 30日 * 0.3GB * 0.1 ■ ブラウザキャッシュヒット率99.9% ○ データ転送量（オリジン）: 0GB/月 ● Amazon API Gateway ○ 種類: REST API ○ リクエスト数: 1000アクセス/時間 ○ キャッシュ: 無し ● Amazon S3 ○ データ保存量: 0.3GB 

コスト計算の例: Amazon CloudFront + Amazon S3構成の静的サイト+API 見積もり結果 https://calculator.aws/#/estimate?id=0079716d5f979d56e326f8e4331e43e9eab72bfa 

コスト確認: AWS Cost Explorer AWS Cost Explorer ● 実際に使われているコストを表示するAWSのサービス ○ リソースごとのコストをグラフ・表形式で可視化 ○ 毎時、日別、月別でグループ化 ○ リソースのオペレーション単位でも可視化 ○ フィルタ機能で条件を絞りながら確認可能 ● 事前の想定よりもコストが掛かっていないか?コストを減らせそうな箇所はない か？など定期的にする ○ 事前の予測から漏れることもある ○ 前のスライドの見積もり例でも、実はAWS LambdaやAmazon API Gateway のログを出力するAmazon CloudWatch Logsが見積もりから抜けている ● コスト配分タグとして定義されているタグは、AWS Cost Explorerでの グルーピングにも利用可能 

クラウド死 使い方次第ではクラウドで膨大な請求を受ける可能性がある ● 要因 ○ 実装・設計ミス ■ サービスによっては、慣れていないと想定外の挙動をする可能性がある ■ 実際に発生した事例 ● Amazon S3のオブジェクト追加がトリガーのAWS Lambda内で オブジェクト追加 ->追加したオブジェクトのパスもトリガーになっており AWS Lambdaが無限に発火し続ける ● AWS Fargateの設定ミスによるコンテナ無限起動 -> AWS Configのコスト増大 ○ 第三者による不正利用 ■ アクセスキー/シークレットアクセスキーの流出 ● 参考: https://qiita.com/saitotak/items/813ac6c2057ac64d5fef