【AWSオンラインセミナーメモ】AWSアンチパターン紹介 #awsblackbelt

AWS AWSオンラインセミナー

　例によってオンラインセミナーを聴講したので、そのメモです。すでに Youtube に動画が公開されていました。

www.youtube.com

個人的サマリ

　今回はかなりボリューミーな内容だったので、最初に個人的なサマリおよび感想／心がけたいことを書いてみます。

クラウドの利点を活かしてとにかく動かしてみる

　机上評価やカタログスペックをにらめっこしてもあまり意味がありません（全くないわけではないが）。まずは動かしてみる／作ってみるという心がけです。

　ただスモールスタートすればいいわけでなく、あとでスケールできるような設計にしておくことが重要です。スケールアップはあとでどうにでもなるのですが、スケールアウトするには、セッション情報は外部にキャッシュするとか、アップロードされたコンテンツを EC2 で保持しないとかの考慮が必要です。

　1台のサーバで開発環境を作ってしまうと、知らないうちにスケールしない作りになってしまうことがあるかもしれないので（あるのかな）、「まずは動かす」段階でも ELB + EC2 x 2台というような冗長化構成にしておくと、このようなアプリレイヤの考慮漏れにも早く気付けるかもしれません。開発環境は1台でいいよー、であれば最終的に1台にスケールインすればいいので。

塩漬け注意

　ここは私も気を付けないといけないと感じたポイントです。過去に自前構築した部分に関連するマネージドサービスが出てきたときに、最低でも「置き換えることでメリットがあるかどうか」までは評価するように心がけたいです。

　置き換えるメリットがあるとわかった時に、次はその対応工数を確保し、検証を行う必要があります。検証は、

  • 現行環境を理解する（アプリからインフラまで）
  • 新機能への理解と実際に試用してみる（素振りする）
  • 移行作業もだいたいの流れを想定しておく

あたりを事前に抑えているとスムーズだと思います。また、

  • 検証環境を少ない工数で用意できるようにしておく（本番ミラー環境がある or 自動構築できるようにしておく）
  • アプリから DB まで E2E なテストを自動化しておく

ことで事前検証の工数を減らせますし、テスト漏れも防げると考えます。

アプリもインフラも

　上のふたつを書いていて思うのは、アプリもインフラも抑えていないと、アンチパターンにハマってしまうと感じました。システム全体を抑えられるよう頑張っていく所存です。

　以下、聴講メモです。

アンチパターンの前に

AWS クラウドデザインパターンとは

  • 典型的な問題とそれに対する解決策／設計方法をノウハウとして整理したもの
  • AWS Well-Architected Framework
    • クラウド設計、構築、運用のベストプラクティス集。質問形式で記載されている。
    • ホワイトペーパーとして提供
    • Serverless に特化したホワイトペーパーなどもある

アンチパターンの紹介

  • 失敗に陥るパターンを類型化し、事例の早期発見および対応策の提案を目的としている。
  • 当初は妥当であったのに、最終的に悪い結果が繰り返されるパターン
  • リファクタリングするための方法が存在する
  • 今回は、タイミング別のメタアンチパターン。今回は下記の分類で紹介。
    • 机上の空論アンチパターン
    • 塩漬けアンチパターン
    • ノーコスト最適化アンチパターン

机上の空論アンチパターン

  • 原因
    • サーバ発注→システムデプロイ→納品というループにハマっていて、完璧を求めすぎている
    • カタログスペック／マイクロベンチマークに過度に頼りすぎ
  • 症状
    • 動作確認をしない
    • 事前のキャパシティプランニングに時間をかけすぎている
  • 解決方法
    • 小さくても試してみる

　「後からいじれない」「塩漬けせざるをえない」という考え方が思考停止を生んでしまう。そういう意味で、残りのふたつをも密に関連する。

塩漬けアンチパターン

  • 原因
    • 構築した当初のままインフラの見直しをしない
  • 症状
    • 実際の利用状況に比べて、キャパシティの過不足を放置したまま利用
    • 一時しのぎで選んだサービスをそのまま使い続けている
  • 解決法
    • サービスは定期的に見直す
    • 新サービス、新機能が助けになることがある

　塩漬けパターンをやめてほしいときによく言うのが、「利用者が担当する作業 vs. AWSが提供する機能」の表を見せる。AWS に運用保守を委譲することで、これらの費用を低減することができる。が、「EC2 に MySQL を導入する」というよう使い方をしたまま塩漬けしていると、このコストメリットを受けることができない。AWS は継続的に新サービス／機能をローンチしているので、それを参考に無駄な塩漬けをしないように気をつけること。

　東京リージョンがローンチされたときは、10以下しかサービスがなかった。今では100以上ある。つまり、7年前は自前で EC2 上にミドルウェアを導入せざるをえなかったことが、今ではマネージドサービスになっていることが多々ある。

　セキュリティの例では、当時は Cloud Watch しかなかったが、今では簡単に導入できるセキュリティサービスがたくさん出ている。Cloud Trail などはその例。変更管理したいのであれば AWS Config を使えばいいし、EC2 インスタンス内のセキュリティ分析をしたいなら Amazon Inspector を使うなどなど。

　サービスアップデートにより、アンチパターンになったパターンの紹介。

NAT インスタンスを EC2 で立てる → NAT Gateway を利用する

　元々は EC2 インスタンスに特殊な設定をしていた。そのため、可用性の担保やスケールアップは利用者側で対応が必要だった。NAT Gateway を用いることで、これらの対応は不要になった。

VPC Peering を使って SaaS 提供 → PrivateLink for Customers and Partners を利用する

　SaaS 提供したいときは、

  • Public IP or CNAME を公開する
  • VPC Peering を用いて Private IP でも接続できるようにする

という大きく２パターンが用いられていた。Peering できる接続先数の制限や、IP アドレスの衝突などの問題があったが、PrivateLink を用いるとこのような問題は発生しなくなった。

時間合わせは Amazon 外に NTP で繋がることもあった → Amazon Time Sync Service を利用する

　NTP を利用者側が考える必要がなくなる。

Auto scale に対応していない WAF アプライアンスを ELB で挟んで機能を補っていた → ELB sandwich for WAF appliance

　苦しい設計だったが、AWS WAF を利用することで適切なアーキテクチャが組めるようになった。

ノーコスト最適化アンチパターン

  • 原因
    • 既存構成を変更できないので何もしない
  • 症状
    • 利用額の高止まり
    • 不必要なリソースの放置、不正利用
    • クレジットカード与信額の使い切り

　スポットインスタンスの活用や運用を自動化するクラウドネイティブなアーキテクチャに変更できるなら、最も削減効果が大きい。また、それが難しい場合でも、利用実績を元に自動的にコスト最適化を提案するツール Trusted Advisor による診断を受けて、少しでもコストを最適化できるようにする。

　ここから過去事例。

  • 状況
    • Redshift を採用した DWH がいつの間にか並列度の高い SQL アクセス用途に使われるようになる
  • 症状
    • 「パフォーマンスが悪い」とクレームになる
  • 解決方法
    • DBの特性を理解し、使ってみて DB の選択を最適化する

　Redshift の特徴を生かせないユースケースもある。並列実行数が多い、短いレイテンシーが必要、ランダムアクセス、集計しない、、などなど。（Aurora との比較資料あり）また、SQL vs. NoSQL も特性に応じて選択すること。

  • 状況
    • 「ストレージ代込」で EC2 が使えると聞いて、インスタンスストアにシステム構築
  • 症状
    • データ消失、容量不足
  • 解決方法
    • ストレージの特性を理解する

　EBS とインスタンスストアの使い分けを行う。インスタンスストアは揮発性。

  • 状況
    • 汎用 SSD の gp2 を使う
  • 症状
    • 速度が足りない
  • 解決方法
    • 最適なストレージを選ぶ

　gp2 以外もあるので、特性を理解しましょう。