Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
第1回 AWS勉強会
Search
Hiroto Sasagawa
July 09, 2023
Technology
0
420
第1回 AWS勉強会
Hiroto Sasagawa
July 09, 2023
Tweet
Share
More Decks by Hiroto Sasagawa
See All by Hiroto Sasagawa
IP Anycastとリバースプロキシ
nagutabby
0
330
HSTSについて調べた
nagutabby
0
320
第1回 GNU/Linux勉強会
nagutabby
0
410
第2回 GNU/Linux勉強会
nagutabby
0
360
第3回 GNU/Linux勉強会
nagutabby
0
390
DNSを標的とする攻撃
nagutabby
0
360
EC2とCloudWatchで始める高対話型ハニーポット運用
nagutabby
0
390
Other Decks in Technology
See All in Technology
Python と Snowflake はズッ友だょ!~ Snowflake の Python 関連機能をふりかえる ~
__allllllllez__
1
120
LLM開発・活用の舞台裏@2024.04.25
yushin_n
1
410
ChatGPT for IT Service Management (IT Pro)
dahatake
7
1.6k
Cypress or Playwright?
rainerhahnekamp
0
110
On Your Data を超えていく!
hirotomotaguchi
2
690
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
3
570
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
310
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
170
自己改善からチームを動かす! 「セルフエンジニアリングマネージャー」のすゝめ
shoota
6
800
複雑な構成要素を持つUIとの向き合い方 〜新・支出グラフでの実例〜 / B43 TECH TALK
nakamuuu
0
140
JSON攻略法.pdf
miyakemito
8
5.1k
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
130
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
YesSQL, Process and Tooling at Scale
rocio
164
13k
Bash Introduction
62gerente
604
210k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
Product Roadmaps are Hard
iamctodd
44
9.7k
Raft: Consensus for Rubyists
vanstee
132
6.3k
Building Adaptive Systems
keathley
31
1.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
Building Better People: How to give real-time feedback that sticks.
wjessup
355
18k
Embracing the Ebb and Flow
colly
80
4.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
187
16k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Transcript
第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を採⽤する • マネージドサービスを利⽤する • サステナビリティのベストプラクティスを⾃動化