AWS Tech talk Night#5 クラウドネイティブ時代のエンジニアが押さえておきたい ソフトウェアの構築・運用で考慮すべき5つのポイント AWSプリンシパルエンジニアの技術記事をソリューションアーキテクトが解説
- 1/25にZoomウェビナーで実施された、AWSのイベント
- イベントURL
概要
AWS Japan 千葉さん
概要
- AWSの最新技術やトレンド
- AWSのSolutionsArchitectの醍醐味
過去のセッションは動画、記事で見れる→AWS -Techplay
今回の元ネタ→AmazonBuildersLibrary
- AWSの上位のエンジニアによって書かれた記事
- 日本語訳もあり
- それの解説
- 開発・運用のノウハウ
- サービス開発・AWS利用に役立てる
必ずしもAWSでなくてもクラウドの設計にも役に立つ
1. キャッシングの課題と戦略
- キャッシュの無批判な導入は危険
- キャッシュのメリットとリスク、あるべき戦略について考える
川島さん
- 得意領域
- 機械学習・画像処理
元記事→キャッシングの課題と戦略
キャッシュ導入運用に考えるべき事項
- キャッシュが必要なのか
- キャッシュ戦略
一般的なキャッシュ運用、AWSでのキャッシュサービスについて
ネットワーク経由のデータ呼び出しで考えること
- 呼び出しのレイテンシ
- 呼び出し量が増えたときのスケールアウト費用
ダウンストリーム(ダウンストリームリソース)
- 呼び出されるコンテンツなどのこと
- これをキャッシュする
AWSにも色々サービスがある
キャッシュの種類2種
ローカルキャッシュ
- ダウンストリームリソースに付属する
- インメモリキャッシュ
- メリット
- 簡単に実装できる
- デメリット
- サーバー間でキャッシュの一貫性が保証できない
- コールドスタート
- サーバー本体の負荷がかかる
- リクエストの合体することで緩和
- ダウンストリームの負荷がサーバー群のサイズに負荷が比例する
外部キャッシュ
- ダウンストリームリソースの外に存在
- 外部のキャッシュサーバー
- メリット
- 一貫性
- コールドスタート
- 負荷がサーバーサイズに比例しない
- ストレージスペースの制約からキャッシュが解放
- キャッシュを大きくできる
- デメリット
- 運用コストの増加
- 新たなサービスの追加
- モニタリング、管理、スケーリング
- 新たなサービスの追加
- 運用コストの増加
運用の注意
- キャッシュ障害の対応
- フェイルオーバー
- ローカルキャッシュとの併用
- 負荷制限の実装・テスト
- キャッシュサーバーのスケーリングと伸縮性
- 適切なメトリクス、閾値でスケール
- サーバー追加削除のテスト
- 複数ノードのキャッシュ書き込み
- トランザクションがないことに注意
- 他のサービスとのバージョニング
- 複数バージョンサービスの運用時に問題がないか
- キャッシュ障害の対応
アマゾンのベストプラクティス
- 他のサービス同様に管理モニタリング
- キャッシュが使えない場合に回復できるようにする
- 他のサービスのバージョニングに対応できるようにする
キャッシュのセキュリティ
- データの暗号化
- 転送中、保管中の暗号化
- キャッシュポイズニング攻撃
- キャッシュに誤ったデータを参照させる
- 対策→ ダウンストリームプロトコルに脆弱性をなくす
- サイドチャネルタイミング攻撃
- 応答時間でキャッシュ保持の有無を判断
- 他のユーザーの履歴などを判断
- データの暗号化
その他キャッシュの考慮事項
- キャッシュサイズ
- 予想されるリクエスト量から決める
- 有効期限ポリシー TTL(Time to Live)
- 削除ポリシー
- LRU (least recently use)
- LFU (least freaquently use)
- キャッシュサイズ
メトリクスを設定してパフォーマンスを追跡し逐次改善する
キャッシュヒット率に影響する
thundering herd
- リソースへのリクエスト同時多発
- コールドスタート時に発生しやすい
- →対策、リクエストの合体
- キャッシュライブラリなどで実施
TTL
- ソフトTTL
- 基本的にはこの時間まで
- ハードTTL
- 不具合があった場合代用
- ソフトTTL
ネガティブキャッシュ
- エラー応答を返す
キャッシュの必要性の観点
- コスト
- レイテンシー
- 可用性
2. 負荷制限を使用して過負荷を回避する
- 負荷制限に関してAWSが考えるベストプラクティスの共有
長友さん
概要
- 一般的な負荷制限の仕組み
- Amazonが考えるしくみ
負荷制限とはなにか
- 理論的にシステムのスケールの限界の見積もりが可能とする法則
- 並列化による処理速度向上には限界がある
- 何％並列処理できるか？
大量リクエストを処理する際にどうするか？
- リソースのスケール
- 性能向上に限界がある
- リトライ・バックオフ
- リクエストの間隔を伸ばしていく
- 場合によっては負荷を増大
- 負荷制限
- リクエストの成功をへらす
- システムが処理する量を制御して性能の一貫性を保つ
- リソースのスケール
負荷制限
- 過負荷の際にリクエストのいくつかは脱落させてシステムを保護
- システム全体をダウンさせずに継続を維持
- パフォーマンスを維持
過負荷の状態
- スループットの状態
- GoodPut
- スループットのうち正しく処理されたもの
- スループットが膨大になる → ClientTimeoutがおきる→Goodputが0になる
負荷制限で何を考慮すべきか、注意事項
リクエストに優先順位
- 優先度の低いリクエストはオフピーク時に処理する
- クローラの処理は優先度低
- ヘルスチェックのためのロードバランサからのPingは優先度高
- 優先度の低いリクエストはオフピーク時に処理する
無駄な処理コストを使わない
- 過負荷時には、レスポンスの遅さからユーザーが頻繁にリトライすることが多い
- 優先度の低いリクエストは削除
クロックの扱いに気をつける
- 無駄な処理を避けるためにClientTimeoutに応じてサーバーは途中で処理中断
- クロックをサーバー間で同期させることが重要
- タイムアウトで無駄が生じる
キューの扱いに注意
- リクエストがキューにされる時間が増える
- キューに置かれる上限時間を定めて古すぎるものは削除
- 成功する可能性の高い新しいリクエストを優先させる
レイヤーごとに保護する
- レイヤーごとに負荷制限を実施。サービスの状況を監視 ＊どこで何が起きて負荷制限をしたのか後で追えるようにする
AWSのアーキテクトが関わった負荷制限の一例
- 新型コロナワクチン接種予約システム
- 予測困難なアクセス数をバーチャル待合室機能で対応
- 要件・課題
- アクセス数の予測が困難
- アクセス数の減少で規模を縮小できる柔軟性
- CloudWatchでモニタリングしAutoScaling
- 新型コロナワクチン接種予約システム
3. Amazonにおけるダッシュボードのベストプラクティス
- ダッシュボードを作成する際のおすすめルール
元記事 → 運用を可視化するためのダッシュボードの構築
吉澤さん
- おすすめのAWSサービス→AWS Trusted Adviser
ユーザーが知りたい情報 → 数値ではなく、実際の行動や判断がほしい
- ex) 天気の具体的な値より、気温に合った服装や傘が必要か知りたい
ダッシュボードも同じで、目的に応じてダッシュボードを構築
Dashboarding
- ダッシュボード大切
- システムをリアルタイムで把握したい
- モニタリング
- 自動修復
- CD
- いつ何がどこで起こっているのか把握できるように
ダッシュボードの24hの張り付き → 人為的なエラー、見落としになるからしない
ダッシュボードのポイント
- アラームの作成
- 重要なモニタリングデータのアラーム→通知
- 迅速に判断できるように
- 複数種類のダッシュボード
- 役割・用途に応じたダッシュボード
- アラームの作成
ダッシュボードの種類
- 顧客志向
- 高レベル
- クライアント目線、監査人目線
- 具体例
- カスタマーエクスペリエンスダッシュボード
- 健全性や外形監視、RUM
- 顧客影響などに答えるように
- システムレベルでのダッシュボード
- システムやエンドポイントが動作していることの確認
- 入出力関連
- システムやエンドポイントが動作していることの確認
- 情報が増えすぎないように
- カスタマーエクスペリエンスダッシュボード
- 低レベル
- 運用メンバー目線
- 機能にフォーカス
- 具体例
- マイクロサービス固有のダッシュボード
- サービスの実装に特化
- インフラストラクチャのダッシュボード
- 依存関係のダッシュボード
- 他のチームのマイクロサービスとの依存
- マイクロサービス固有のダッシュボード
- 高レベル
- 顧客志向
ダッシュボードの設計
- チームに参加した人が学習しやすいように標準化をした
- 記事にベストプラクティスがのっている→リンク
ベストプラクティスの抜粋
- 最重要なデータを一番上に
- グラフのレイアウトは想定できる最小のディスプレイサイズに合わせる
- 横スクロールをなくす
- インシデントなど咄嗟のときに気づかない
- 横スクロールをなくす
- アラームを設定する場合はグラフに閾値を表示する
- MLの異常検知でも正常範囲を描画
- 各メトリクスもしくはウィジットの真の意味をユーザーが理解していることは前提にしない
- ウィジットの説明文を追加
- システムに応じて状況に応じた複数のウィジットを用意する
- Get API/Put APIで場合分けすることで原因をわかりやすく
保守運用
- 開発者が自分自身でアップデート
- 改善の実践方法
- 新機能をデプロイする前にダッシュボードになにか変更はありますか？と質問をはさみダッシュボードを更新する
- ステージングにも同様のダッシュボードを用意
- ダッシュボードのレイアウトをIaCで採用、VCSで管理
- 障害発生後
- ダッシュボードの反省
- 顧客影響を明確にしたか
- 障害原因を明確にすることに貢献したか
- 修復時間を短くすることの助けになったか
- ダッシュボードの反省
- 新機能をデプロイする前にダッシュボードになにか変更はありますか？と質問をはさみダッシュボードを更新する
4. 分散システムの課題とリーダー選挙
- 分散システムを構築・利用する際に知っておきたいポイント
- 分散システム間での一貫性を保ったステート管理
- 参考記事 → 分散システムの課題
元記事→分散システムのリーダー選挙
松田さん
分散システムとは
- 多数のコンピュータがネットワークで繋がり、連携して一つの作業を行うシステムのこと
オフライン分散システム
- 大規模計算処理を可能に
- コストの最適化
オンライン分散システム
- 耐障害性・可用性
- 世界中からのアクセスのレイテンシの改善
- ソフトリアルタイム
- 遅延が多少許される
- ハードリアルタイム
- 遅延がほぼ許されない
分散システムの課題
- 悲観的な認識を持つ
- 分散システムは壊れる
- 平均故障間隔5年のコンピューター
- 2000台ある場合一日一台平均で壊れる
- 参加ノードの障害の例
- リクエストが到達しない場合
- リクエスト側からはレスポンスが待つがこない
- レスポンス前に故障
- ステートを更新中に故障
- →送信ノードからは故障がわからない、時間が経てば復旧するかもしれない tail latency
- リクエストが到達しない場合
- 送信ノードはタイムアウトとして処理の終了ハンドリング
- 受信ノードはステートの更新処理は冪等性をもたせる
- 分散システムは壊れる
- レプリケーション
- 例：飛行機予約
- 予約の情報共有とレスポンス
- 情報共有の遅延、失敗したとき、他のノードから予約できてしまう
- コンフリクトが発生
- 例：飛行機予約
- 対策→リーダーノード
- データの整合性担保をリーダーノード内で完結
- 各操作ごとにノードの合意を得る必要がなくなる
- 多数決を用いた分散システムに比べ実装が容易
- AWSRDSでのレプリケーション
- Multi-az配置では同期レプリケーション
- リードレプリカでは非同期レプリケーション
- 悲観的な認識を持つ
分散システムにおけるリーダー選挙
- リーダーの決め方
- ノードの固定
- 分散合意
- アプリケーションの利用
- lease
- リーダーである権利を期限付きで取得
- ローカルのプロセス時間で権利を渡す
- 課題
- 処理時間の保証ができない
- ロッククライアントライブラリの利用
- 十分な期限が長くするとリースの交換に処理がとられる
- 処理時間の保証ができない
- リーダー障害対策
- 冪等性担保
- リーダーの決め方
5. 高可用性を実現する静的安定性という考え方
- クリティカルなシステムを運用する際、機能性と可用性をどのように両立させるか
- 『アベイラビリティゾーン』を使用し冗長化を行う際のポイント
元記事 → アベイラビリティーゾーンを使用した静的安定性
堀さん
高いパフォーマンス高機能高可用性を実現するのに静的安定性が必要
依存に障害が発生しても動くように
静的安定性とは
- 障害で依存関係が損なわれてもシステムが動作し続ける性質
必要な理由
- システムの高可用性は依存するシステムの可用性が高い必要性がある
- 高パフォーマンスで高機能なAWSサービスを作る上ですべての依存先の可用性を高く保つのは困難
実現するシステム
- sys1はsys2に依存
- sys1はキャッシュをもって安定性を作る
AWSの静的安定性
- コントロールプレーンとデータプレーンの分離
- データプレーン
- サービスの基本機能。高い可用性、単純な依存
- コントロールプレーン
- システムの変更
- 複雑な依存
- データプレーン
- ex) EC2
- データプレーン
- ネットワーク、サーバー、ストレージ
- コントロールプレーン
- インスタンス作成、設定変更
- データプレーン
- コントロールプレーンとデータプレーンの分離
アベイラビリティゾーン(AZ)を使用した例
- AWSサービスを使った場合の例
- AWSのアベイラビリティゾーン
- 意味のある距離で物理的に分離
- 高速で暗号化されたプライベート光ファイバーネットワークで相互に接続
- 複数のAZにEC2を配置する
- ELBで分散
一般的なアーキテクチャにおける静的安定性
- →何らかの障害の際にコントロールプレーンに依存しない設計に インスタンス作成がコントロールプレーンに依存
- AutoScaleでなくなる
- → 2つのAZインスタンスを200％用意、Autoscaleの設定は負荷テスト時の50% コスト大
- → 3つのAZインスタンス150%Autoscaleの設定66.6% 障害時にインスタンス作成の必要がない。コスト低
DBを使ったアーキテクチャの静的安定性
- 通常時のRDSから他のAZのスタンバイに移行する。フェイルオーバー
Q&A
Q1
インフラとは直接関係ない質問です。
キャッシュサーバーが含まれる構成から、データを取得する流れにについて質問です。 クライアントプログラムは、まずキャッシュ取得をトライして、 キャッシュになかったら本体からデータ取得する流れになるのでしょうか？
データ取得時に、キャッシュサーバーの存在を意識しないプログラムがかけると良いと思いますが、いかがでしょうか？
A1
サイドキャッシュ ダウンストリームリソースを意識する キャッシュがなくてもアプリで対処できる 選択肢にしやすい
インラインキャッシュ ダウンストリームリソースを意識しない バグ要因減らせる
Q2
オンプレADと時刻同期しているサーバーと、AWSのタイムサーバーと同期しているサーバーが同一システムで動いているのですが、負荷制限をするには、やはりタイムサーバーを統一した方が良いでしょうか。
A2
ご質問ありがとうございます。 各サーバで別々のタイムサーバを使用する状況もあるかと思いまが、AWSのタイムサーバとオンプレADでクロックがズレてしまった場合にシステムで不整合が生じてしまいます。タイムーサーバを統一した方がいいケースが多いのではないかと思います
Q3
ダッシュボードをupdateしていく上でどのステークホルダーを重視するべきでしょうか？
A3
ダッシュボードを作成する際には、それを使うユーザーと目的を考えながら設計していくという考え方がAmazonでは基本となっています。
ですので、ダッシュボードをupdateする際も同様で、設計する際に想定したユーザーを考えながら変更点を考えていくことになると思います。
また、レイアウトをIaCとしてバージョン管理することによって、場合のよってはロールバックできるようにすることも大切となります。
Q4
データプレーン、コントロールプレーンはコンテナサービスにのみ使用する用語だと思っていました
A4
結構色々なシステムでこの用語は使われますね！NWの世界でもNW経路制御をするところをコントロールプレーン、フレーム転送をするところをデータプレーンと呼んだりします。
Q5
静的安定性の住所サービスの例について。 古いキャッシュを使って見かけ上動作させると、住所を更新しても新しい住所が使われず不具合になることがあると思います。 その辺りを検討した上で静的安定性を作り込むのでしょうか？
この例とコントロールプレーンの話は、別の話に聞こえました。
A5
このような場合は障害発生した場合は障害発生するが、使われないようにする コントロールプレーンを時間をおく工夫
各システムでどこが生かしつづけるシステムか、可用性を下げてもよいか、判断する。可用性とコストはトレードオフ
Q6
EC2を用いた例をたくさん示していただきありがとうございました。現在、Fargateのみを利用しているのですが、EC2と異なり気をつけるところはありますでしょうか。特に最後のプレゼンテーションの静的可用性について、気をつけるべきことがあればぜひ教えていただきたいです。
A6
サーバーレスやマネージドのサービスを使って静的安定性をAWS側に実施してもらう手段になる
感想
- 2時間連続休憩なしのイベントだったので疲れた
- 登壇者が好きなAWSサービスについて述べるのはAWSっぽくて面白い
- AWSに限らないクラウドのアーキテクチャにまつわる話で興味深かった
- キャッシュにまつわる話がよかった