Zenn
💬

AWS Well-Architected Frameworkから学ぶエンジニアリングの知識

2023/02/26に公開・約6,200字
AWS
#
リンク集
idea

AWS Well-Architected Frameworkは、様々なアプリケーションやワークロード向けに対応したアーキテクチャを設計・運用するためのベストプラクティス集です。

公式ドキュメントはアプローチとそれに付随したAWSのサービスの利用についてメインに書かれています。
AWSに限らず、より汎用的な知識も身に着けるために有用だと思ったので、個人的に学びのあった記事や事例を集めています。(随時追加)

AWS Well-Architected Framework

https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc

運用上の優秀性

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/welcome.html

コードによるオペレーション(IaC)
  • CloudFormationやTeraformを利用したデプロイの自動化

https://cloudify.co/blog/terraform-cloudformation/

https://cto-a.org/news/2020/09/28/3367/

障害時の対応

  • 収集したログ・メトリクスに対してフィルター及びアラームを実装

  • CloudWatchとかよりは最近は監視Saasが大体利用されている印象

https://qiita.com/MetricFire/items/d07fce3b2d001db8d94f

https://www.webiscope.com/articles/cost-comparison-new-relic-vs-datadog-vs-dynatrace/

変更の品質保証
  • 問題が発生した時のロールバックや分割リリースなど、被害を軽減できるリリース方式を準備する

https://qiita.com/minorun365/items/3c92187cb251abbd92bc

セキュリティ

https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

  • アイデンティティ管理とアクセス管理
利用者ごとのIAMユーザー作成
  • ユーザごとのポリシーの設定、MFAの設定、操作の追跡を行う

https://qiita.com/montama/items/90bb8a3973d101be4690

IAMロール
  • プログラムにIAMユーザーのアクセスキーを付与しないで、ロールを使用する(キーの流出を防ぐ)

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys.html

最小権限の原則
リソースポリシー
  • 利用するサービス側でもアクセス管理を行う

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_identity-vs-resource.html

(CloudTrailの)ログ
  • ログを参照して失敗の原因を探る

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/c301.html

マルチアカウント
  • 開発・ステージング・本番でアカウントを分ける

https://qiita.com/mastar_3104/items/76739b05886d5bd42d90

伝送中及び保管中のデータの暗号化
全レイヤーでの多層防御
  • 各レイヤーごとに対策を講じる必要がある。

https://xtech.nikkei.com/it/article/COLUMN/20140129/533159/

インシデント対応
  • インシデントが起きた場合に迅速に検知・対処し影響を最小化する必要がある。

https://www.atlassian.com/ja/incident-management/devops

https://engineering.mercari.com/blog/entry/2018-04-10-090453/

信頼性

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/welcome.html

復旧手順のテスト
  • 障害発生のシミュレーション

https://qiita.com/naokiiiii/items/de20997a70922c01f754

https://fintan.jp/page/6394/

障害からの自動復旧
  • 閾値を設けて負荷状況などが超過した場合にトリガーを設定し、問題が発生した場合にリソースの追加や交換を行う。

https://newrelic.com/jp/blog/best-practices/new-relic-reliability-incident-learning

スケーラブルなシステム

まずは水平方向にスケールすることを考える　(単一コンポーネントで障害が起こっても他のサービスでサービスが継続できる、セッションなどは持たずステートレスにする必要あり)

https://wa3.i-3-i.info/diff541system.html

キャパシティ推測を不要に

  • 一般的にWebサーバやアプリケーションサーバはスケールアウトが容易だが、DBサーバーはスケールアウトが難しい。

    • 参照系と更新系を分離する
    • 参照系はリードレプリカを利用し、スケールアウト可能
    • 更新系はスケールアップし処理性能をあげる

http://engineer-memo.net/20200305-5241

バックアップと復元
  • 定期的なバックアップをとり、エラー時に確実に復旧できるようにする。
    RTOやRPO等のビジネス要件に基づき決定される。

https://pfs.nifcloud.com/se_handbook/Backup-Overview.htm#_バックアップリストア方式検討時の考慮ポイント

パフォーマンス効率

https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html

  • リソースの選択
コンピューティング
  • インスタンスなど、過少でも過剰でもない適切なリソース種別を選定することが必要。

https://it.impress.co.jp/articles/-/14727

https://zenn.dev/matsu7089/articles/meaning-of-ec2-instance-types

ストレージ
  • インスタンス側とボリューム側のIOPSとスループットのうち、どこにボトルネックがあるかをメトリクスから取得s、適切なリソース種別とキャパシティ設定を見極める。

IOPS: 一秒あたりの入出力操作数で、ストレージデバイスが処理できる操作の量

スループット: 一秒あたりに処理できるデータの量で、ストレージデバイスが処理できるデータの量

レイテンシ: ストレージにアクセスするために必要な時間

https://zenn.dev/satoru_takeuchi/articles/29aff45fa5c9a776c1a4

データベース
  • RDBMS、NoSQLの選択が第一。
  • RDBMSは汎用的に利用可能だが、水平方向へのスケーリングは苦手。

https://www.ml4devs.com/articles/datastore-choices-sql-vs-nosql-database/

ネットワーク
  • インスタンスごとのネットワーク帯域の限界がある。
  • CPUやメモリに余裕があるのにパフォーマンスが出ない場合は、インスタンスのネットワーク帯域の上限に達している可能性がある。
  • インスタンスからブロックストレージ(EBS)へのアクセスはネットワーク経由のため、ストレージへのアクセスがボトルネックになる場合もある。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-latency-ebs-iops-bottleneck/

リソースの確認とモニタリング
  • システム構築後も継続的なモニタリングが必要。
  • モニタリング中に閾値を超えた場合は適切な対応が必要
    • 例)RDSのパフォーマンスを高めたい→キャッシュを挟む
    • 例)RDS Proxyを利用してDBコネクションをプールして共用する

https://software.fujitsu.com/jp/manual/manualfiles/m110005/b1ws0842/02z200/b0842-01-04-04-01.html

トレードオフの判断
  • パフォーマンスの向上は整合性、耐久性、レイテンシーの余裕と引き換えに実現されるケースがある。→キャッシュの利用(DB:Redis,コンテンツ:CDN)

https://www.cloudflare.com/ja-jp/learning/cdn/what-is-a-cdn/

https://medium.com/techmonks/redis-vs-memcached-which-one-to-pick-401b0c3cbf94

コスト最適化

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/cost-optimization-pillar/welcome.html

需給の一致
  • ピーク時に備えてあらかじめ大量のリソースを用意しない

https://aws.amazon.com/jp/cdp/forecast/

インスタンスの購入方法によるコスト削減
  • リザーブドインスタンスや、スポットインスタンスの活用

https://japan.zdnet.com/article/35176270/

アーカイブストレージの活用
  • 低頻度アクセスクラスのストレージに変更する
コストの把握
  • 月次の請求以外にも常時で現在の利用額を確認する

https://www.softbank.jp/biz/blog/cloud-technology/articles/202208/cost-saving/

サステナビリティ

https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html

https://aws.amazon.com/jp/blogs/news/sustainability-pillar-well-architected-framework/

  • 影響を把握する
パフォーマンス指標を確立し、改善を評価する。

https://blog.recruit.co.jp/rls/2021-03-31-four-keys/

サステナビリティ目標の設定
  • ROIを意識したエンジニアリング

https://devblog.thebase.in/entry/2021/10/20/110000

使用率の最大化

https://developers.freee.co.jp/entry/freee-tech-night-aws-cost-control

より効率的な新しいハードウェアとソフトウェアの提供を予測して採用する

https://codezine.jp/article/detail/16259

Discussion

ログインするとコメントできます