この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ご機嫌いかがでしょうか、豊崎です。
2018年5月22日のAWS Black Belt Online Seminar 失敗例を成功に変える AWS アンチパターン を拝聴しましたので、レポートします。
スピーカーは、アマゾンウェブサービスジャパン株式会社 • 技術統括本部 シニアマネージャー プリンシパルソリューションアーキテクトの荒木 靖宏さんです。
レポート
アンチパターンの前に
AWSクラウドデザインパターン
AWSクラウドを使ったシステムアーキテクト設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、わかりやすく分類して、ノウハウとして利用できるようにしたもの
AWS Well-Architected Framework
AWSの10年以上の経験からクラウド設計、構築、運用のベストプラクティス集
- ５つの柱がある
- セキュリティ
- 信頼性
- パフォーマンス
- コストの最適化
- 運用性
アンチパターンの紹介
成功事例は「パターン」として受け継がれて来ましたが、 それらの一部は「秘伝のタレ」化や、触ってはいけないものになっている。
アンチパターンとは
失敗に陥るパターンを類型化して、反面教師とする。 動作やプロセス、構造について当初は妥当だったが、最終的に悪い結果が繰り返されるパターン リファクタリングするための方法が存在するパターン
覚えていただきたい「メタ」なアンチパターン
- 机上の空論アンチパターン
- 塩漬けアンチパターン
- ノーコスト最適化アンチパターン
机上の空論アンチパターン
オンプレミスの時代サーバを発注、システムをデプロイして納品をする。
納品をする人には責任がある。納品後には修正できません。であれば完璧なものを納品する必要がある。
- 原因
- サーバ発注、システムデプロイ、納品。の硬直したループにはまる
- （最初から）完璧を求めすぎる
- カタログスペックやマイクロベンチマークに過剰に頼る
- 症状：利用前に発生する。
- 動作確認をしない
- 事前のキャパシティプランニングに時間をかけすぎる
- 解決方法
- まずは小さくても試す
- AWSではイニシャルコストがかかるサービスはほとんどない
- まずは小さくても試す
- 備考
- 塩漬けとノーコスト最適化と結び付くと最悪の結果に
塩漬けアンチパターン
- 原因
- 構築した当初のままインフラの見直しをしない
- 症状
- 実際の利用に比べてキャパシティの過不足を放置している
- 一時しのぎで選んだサービスをそのまま利用している
- AWSは継続的に新機能をリリースしている
- 解決法
- サービスは定期的に見直す
- 新サービスや新機能が助けになる
マネージドサービスを利用するとお客様が作業する範囲が非常に小さくなる。
運用のコストが大きく削減できる
セキュリティ関連のサービスはどんどん新しいものが出て来ている。セキュリティ関連のサービスを有効化しましょう。
AWSのサービスアップデートによりアンチパターンになったパターン
左から右への置き換えを検討するべき
- HA NATインスタンス → NAT Gateway
- Auto Scale NAT → NAT Gateway
- VPC Peering を使ったSaaS提供 → PrivateLink
- NTPサーバの参照 → AmazonNTP（Amazon Time Sync Service）
- WAFアプライアンス on EC2 w/ELB → AWS WAF
- 筆者注 : AWS WAFが全てのケースにマッチするとは限らないので、マネージド型WAFとして選択肢が増えると捉えました
ノーコスト最適化アンチパターン
コストの最適化をしない。というアンチパターン
- 原因
- 既存構成を変更できないので何もしない
- 症状
- 利用額の高止まり
- 不必要なリソースの放置、不正利用
- クレジットカードの与信額の使い切り
- 解決策
- 変更できない構成であれば、構成変更が不要なコスト最適化を行う
- 割引オプションの活用
- 細かいリソースの無駄チェック
- Trusted Advisorで指摘されたリソースの見直し
- 使用率の低いEC2や利用頻度の低いEBS、関連づけられていないEIPなどを指摘
- Trusted Advisorで指摘されたリソースの見直し
- コスト最適化の詳細は「AWS Black Belt 2017 AWSのコスト最適化 リザーブドインスタンス」を参照
- 変更できない構成であれば、構成変更が不要なコスト最適化を行う
観測例：DBの使い分け
- 状況
- Redshiftを採用したDWHがいつの間にかパフォーマンスが高いDBとして、用途に向かない並列度の高いSQLアクセス用途（OLTP）に使われるようになる
- 症状
- 「パフォーマンスが悪い」という意見がでる
- コストパフォーマンス
- リプライが帰ってくるまでの時間
- etc..
- 「パフォーマンスが悪い」という意見がでる
- 解決法
- DBの特性を理解する
- Redshiftが向く用途を理解する
- 巨大なデータ・セット（数百GBからペタバイト）
- １つ１つのSQLが複雑だが、同時実行SQLは少ない
- データの更新は一括導入
- ユースケース
- DWH
- ユーザがクエリを作成する（自由クエリー）（BIなど）
- 苦手な箇所
- SQLの並列実行数が多い
- RDSを検討
- 低レイテンシーが必要なケース
- ElastiCacheやRDSを検討
- ランダム＋パラレルな更新アクセス
- RDSもしくはDynamoDB（NoSQL）を検討
- 巨大なデータを格納するが集計しない
- DynamoDBや大きいインスタンスのRDSを検討
- SQLの並列実行数が多い
- Redshiftが向く用途を理解する
- 使ってみて気づいたら構成を見直す
- DBの特性を理解する
データストアの特性を理解しましょう
観測例：ストレージの使い分け
- 状況
- 「ストレージ代込み」でEC2が利用できると聞いて、インスタンスストアにシステム構築
- 症状
- データの消失、容量不足
- 解決法
- ストレージの特性を理解する
インスタンスストアとEBSの違い
観測例：EBSの使い分け
- 状況
- 汎用SSDのEBS（gp2）にシステム構築
- 症状
- 速度（IOPS、スループット）に不満
- 解決策
- EBSそれぞれの特性を理解しましょう
- EBSのボリュームタイプ
- ４種類（現行世代）ある
- Snapshotを経由すればボリュームタイプや容量を変更可能
- ブートボリュームになれるのはSSDのみ
- 性能重視ではプロビジョンドIOPS SSD（io1）が選択されがちだがスループット最適化HDD（st1）の選択肢もある
- EBSのボリュームタイプ
- EBSそれぞれの特性を理解しましょう
まとめ
- アンチパターンにはリファクタリング方法が存在する
- ３つの避けるべきタイミング別のメタアンチパターン
- 机上の空論アンチパターン
- 塩漬けアンチパターン
- ノーコスト最適化アンチパターン
- AWS Well-Architected Frameworkが手助けします
さいごに
アンチパターンとして紹介された内容はオンプレミスの感覚をクラウドにそのままもってきた場合に起こる可能性が高いのではないかと感じました。日々新しい技術が提供されるAWSに置いてサービスを試すこと、知ること、また、それをシステムに適用できるか継続的に考えることが必要だと再認識できました。
14
