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
開発生産性向上サービスを作るFindyが自分たちで開発生産性を爆上げした組織づくりの歩み / Findy's path to boosting its own development productivity 2024-04-17
ma3tk
3
650
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
3
180
プラットフォームってつくることより計測することが重要なんじゃないかという話 / Platform Engineering Meetup #8
taishin
1
350
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
360
反実仮想機械学習とは何か
usaito
PRO
11
4.4k
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
2.1k
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
300
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
120
一生覚えておきたい「システム開発=コミュニケーション」〜初めての実務案件振り返りLT〜
maimyyym
0
130
よく聞くけど使ったことないソフトウェアNo.1 KafkaとSnowflake
foursue
4
350
Featured
See All Featured
Unsuck your backbone
ammeep
663
57k
Why Our Code Smells
bkeepers
PRO
331
56k
VelocityConf: Rendering Performance Case Studies
addyosmani
320
23k
A Tale of Four Properties
chriscoyier
151
22k
How to train your dragon (web standard)
notwaldorf
73
5.2k
A better future with KSS
kneath
231
16k
We Have a Design System, Now What?
morganepeng
43
6.7k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
The Power of CSS Pseudo Elements
geoffreycrofte
60
5k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
322
20k
Practical Orchestrator
shlominoach
182
9.7k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
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を採⽤する • マネージドサービスを利⽤する • サステナビリティのベストプラクティスを⾃動化