はじめに
はじめまして、オクトSREチームの@DanKadoiです。 github.com
普段は、
- AWS上でのインフラ構築
- Docker･Kubernetes環境整備
- CI / CD サイクルの改善や効率化
- プロダクト初期フェーズにおける様々な運用課題の解決支援
- インフラやアプリケーションのモニタリングの仕組みを整備
- OS、ボリューム、ネットワーク、AWSアカウントのセキュリティ対策
etc.. などの技術領域で、日々少しずつ会社貢献しています。
Terraformを用いたIaC(Infrastructure as Code)や、運用負荷の低減/耐障害性の強化などを目的としたインフラ構成の改善、サーバレスアーキテクチャ(過去記事参照)への移行、開発量･成果･費用対効果･処理効率などを可視化するためのメトリクス取得法の確立、より高度で高効率なKubernetesによるコンテナ運用、GitHub Actionなど、手につけたい技術は他にもまだまだたくさんあります。 tech.88oct.co.jp
知らない技術や新しい仕組みをインフラ(あるいはプロダクト)に導入して運用を軌道に乗せるには、苦難がつきものです。
雑多な差し込み業務を捌きながら、唐突に発生する障害の事象確認をしつつ、日々の業務に平行して新しい仕組みを導入するための検証･調査を実施するのは一定のハードルがあります。
しかし、障害 は嫌でも発生してしまいますし、説明を求められれば事実確認が必須となります。
なので私は、事象の詳しい確認･調査の難航が容易に見越せて、尚且つ、早急な解決を求められている場合は、AWSの技術的なサポートを積極的に利用させて頂いております。
今回は、私がAWSサポートへ技術的な問い合わせをする際に気をつけているポイントについて、事例紹介と併せて解説させて頂きたいと思います。
AWSサポートとは
AWS 使用料の月額のうち数%(サポートプランやAWS使用料で変動)を支払って、AWS Trusted AdvisorやAWS Personal Health Dashboardなどを含め、特別なサポートをAWSから受けられるサービスのことです。
aws.amazon.com
「技術的な問い合わせ」には、事象や問題をスムーズに確認･解決するために培われた コミュニケーションナレッジ があります。
それは、だれが,どこに,どのような 問い合わせをする場合においても、変わらず在ると、私は考えています。
分かる人がこの記事読めば そんなの当たり前だ と思うかもしれませんが、基本に立ち返る良い機会だ くらいに受け止めて閲覧頂けますと幸いです。
サポートプランに加入する方法
ご利用中のAWSアカウントにて、rootユーザでログインして頂き、以下のドキュメントに沿ってプラン変更の操作をしてください。 aws.amazon.com
スムーズに解決したAWSサポートへの問い合わせ事例
本番環境で起こったこと
2020/02/16 午後
ANDPADの社内環境にて、AWS CognitoでGoogle認証(過去記事参照)をかけているページをChromeで開こうとすると、ERR_TOO_MANY_REDIRECTSのエラーを出して認証ページに到達しない現象が発生し、環境利用者から問い合わせを受けました。
tech.88oct.co.jp
取り急ぎ、上長およびセキュリティチームから、「他のブラウザをからアクセスすれば発生しないので一旦それで回避してほしい」といった旨のアナウンスを社内向けに出してもらい、私の手元(macOS Catalina 10.15.3, Chrome80系)で事象の再現を確認し以下のように整理しました。
発生条件： ■(OS問わず) Chromeのバージョン80.xxx以上を利用している端末で発生する ■■ERR_TOO_MANY_REDIRECTSが出て、Cognito認証後のページに全くアクセスできず画像1のエラーがブラウザに表示されているケースがある ■■シークレットブラウザを使ったり、googleアカウントの再ログインなどを行ってアクセスを試みたりして、Cognito認証後のページに到達できるが、画像2のエラーが開発者モードで確認できるケースがある 発生しない条件： ■Chromeを使っていても、バージョン79.xx以下のままアップデートしていない環境では、発生しない ■Chrome以外のブラウザを利用すれば、Cognito認証(googleアカウントログイン)通過後のリダイレクトが正常に行える
本件の場合、本番環境で発生したためALBの再作成といったサービスダウンタイムが発生する作業を実施しづらく、頻繁に利用される社内環境であったため、AWSサポートに技術的な問い合わせをして早急な解決を図りました。
AWSサポートに問い合わせを送る際に私が気をつけたポイント
本番用のAWSアカウントにて本件に該当するリソースを確認し、以下のようなテンプレートでAWSサポートに問い合わせのメッセージを送信しました。
${いつもの冒頭挨拶}
発生事象：
${本番環境で起こったこと に記載の通り}
■該当するリソース
■■ALB ${ARN}
■■リスナー ${ARN}
■■リスナールール ${ARN}
■■インターネット経由でアクセスする際のURL ${エンドポイントのURL}
■■Cognito認証を以下の通り利用している
ユーザープール ID: ${ARN}
( プール arn: ${ARN} )
クライアント ID: ${ID}
セッション Cookie: ${Cookie種別}
セッションタイムアウト: ${Time}
認証されていない場合: ${アクション種別}
スコープ: ${スコープ}
■■転送先
ターゲットグループ: ${ARN}
( ${ターゲットグループに紐付くリソースにデプロイされているアプリケーションの説明} )
発生条件：
${本番環境で起こったこと に記載の通り}
発生しない条件：
${本番環境で起こったこと に記載の通り}
問い合わせ：
本件を早急に解決したい と考えいて、解決手段を模索しております。
本件は、Chrome 80におけるSameSite Cookie仕様変更の影響で発生している と考えて良いでしょうか。
また、上述しております該当もしくは関連するawsインフラリソースにおいて、本件の原因となりうる問題が発生していないかご確認いただけますでしょうか。
気をつけたポイントは以下の通りです。
- 何が、どのリソースで、どのような条件で発生し、何に困っているかを、正確に言語化する
- 読み手の調査に手間や時間がかからないように、リソースのユニークIDはすべて記載する
- 読み手が「何に回答して欲しいのか」に悩まないように、問う内容とその補足情報を明確に区別する
- 添付ファイルは、タイトルで中身が推察できるようにしつつ、文章内で参照できるようにする (画像1など)
実は、開発環境でも数日前に発生していた
本件に極めて類似する事象が、ANDPADの開発用のAWSアカウントでも、2020/02/13 午後 に確認されていました。
その際は、Cookie headerの文字数が4,096を超えているところまで確認し、最終的に関連するALBリソースを再作成することで事象の復旧を確認しました。
( ※開発用のAWSアカウントは、サポートプランに加入していなかったため、当時AWSへの問い合わせは断念していた)
開発用のAWSアカウントのその後...
開発部の執行役員と交渉して、開発用のAWSアカウントもサポートプランに加入して頂く運びとなりました。
加入の意図としては、以下のような説明をしました。
- これまで運用してこなかったAWSのマネージドな仕組みや新しい技術をプロダクトで使おうと思った際に、稀に検証段階でテクニカルサポートが欲しいケースがある
- 本番適用前なので、本番用のAWSアカウントにリソースがなく、テクニカルサポートを受けられない
- 真新しい技術で日本語記事がインターネット上に少ない段階だと、調査が難航したりする
- 複数のAWSアカウント間でリソースを共有して連携するようなケースが近年増えてきて、共有先のAWSアカウントでマネージドな機能を利用する際にIAM権限回りの問題が発生して調査が難航しやすい
- アカウントをまたいでサポートに状況確認してほしい場合、共有先のアカウントがサポートプラン未加入の場合、対応してくれるかわからない
- 開発用のAWSアカウントで数日前に発生した障害が、サポートプラン未加入のためAWSに問い合わせできず原因調査も難航したため、リソースを再作成することで強引に復旧させた。しかしその後、本番用のAWSアカウントでも同様の問題が発生してしまった(まさに本件のケース)
などを解決したい。(未然に防ぎたい)
これからステークホルダーに対してAWSサポートプランの加入交渉をしようと考えている運用チーム/SREチームの方は、加入によって増えるコスト と 加入したら享受できる恩恵 を天秤にかけた結果が、先方に伝わるように説明できれば良いと思います。
意思決定者と交渉するのもSREの仕事です、その参考になれば幸いです。
問い合わせ後のAWSサポートによる素早い対応
先方の担当者の方に、問い合わせ内容のホスピタリティを褒めて頂けました。
回答を要約すると、以下のような内容でした。
- 該当リソース(ALB)に対し、「Cross-Origin Resource Sharing (CORS) リクエストの際に SameSite 属性が必要となるブラウザのために、Application Load Balancer の認証機能において ‘SameSite=None’ を付与する変更」が加えられた
- この変更によって、クライアントがバージョン 80 以降の Chromium ベースブラウザを使用する場合において、Load Balancer が Authentication Cookie にこの属性を含める形となった
- これによって、Cookie のサイズが許可されるサイズよりも大きくなるという問題が見つかった(文字数が上限を超える)
- 御社のALB に対して、この変更のロールバックを実施した
- 現在、全ての Load Balancer に対してロールバックを実施している段階である
本事象に関連する情報：
https://forums.aws.amazon.com/ann.jspa?annID=7413
Chromium (web browser) - Wikipedia
まとめ
スムーズな事象解決を目指した問い合わせのナレッジとは
これまでの私の業務経験を元に、問い合わせの文章がどの程度の情報を持っていればその後のやり取りがスムーズになるか、箇条書きでまとめてみました。
今後、サーバやアプリケーションで発生した何らかの事象について問い合わせをしたい方は、問い合わせ先がどこであっても、以下に気をつけて頂ければ良いかと思います。もちろん、下記をすべからく満たしている必要はありません。
- 自分の状態を具体的に説明する
- どのような事象･問題が発生しているか
- どのような環境で発生しているか
- (AWSの)どのインフラ･リソースで発生しているか
- 誰が･何に･どのように困っているか
- (解決した場合)どのような状態であることが、正であるか
- いつまでに、どうなっていたいか(希望･期待)
- 自分で収集できた、関連し得る情報を共有する
- 事前に確認することができた事実や調査結果
- 関連が疑われる挙動･異常･操作
- 関連するログファイルを添付
- 事象を手元で再現したときの様子をgifやスクリーンショットなどで添付
- 誰が読んでも概ね同じような解釈ができる文章を書く
- 主語を省略しない
- 技術やリソースの固有名詞は正確に記載する
- 隠語･造語･略語･社内用語はなるべく使わない
- あなたの問い合わせを受けとる人間は、あなたの親友でも家族でもないことを念頭に入れておく
おわりに
問い合わせの多くは、2~5個の質問をし返さないと、調査に着手することすら難しい程度の情報量 しか持っていません。この記事は、読んだすべての方の業務が、今までより少しでもスムーズに回ることを願って書きました。読んで振り返ったナレッジを、些細な質問からでも、是非実践してみてください。
