この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは。
AWS事業本部コンサルティング部@東京オフィスの芦沢(＠ashi_ssan)です。
今回は2022年10月8日に開催されたJAWS-DAYS 2022 - Satellitesのセッションレポートを行います。
セッション概要
概要
AWSサポートの方々6名が大集合！怒涛の6連続LTチャレンジが繰り広げられます。
公式サイトの概要はこちら
登壇者
小武 三博さん、こだか かおるさん、角川 宗近さん、立野 広樹さん、高橋 尚久さん、田中 智大さん
動画
レポート
AWSサポートから来ました！ 小武 三博さん
- AWSサポートの6名でLTをやっていくよ！
- AWSサポートの紹介
- Technical：技術
- Non-Technical：アカウント、請求
- 無償プランと3つの有償プラン
- 日本語ネイティブエンジニアによる24365サポート
- 日本、ダブリン、シアトルでやってます
- 依頼できること
- 機能に対するHowto
- ベストプラクティス
- API等のトラブルシューティング
- 3rdParty製アプリケーション（OS、Webサーバー、Eメールなど）
- できないこと
- コードの開発やソフトウェアのデバッグなど運用の代行につながること
AWS サポートエンジニアの一日 こだか かおるさん
- サポートエンジニアの朝は早い？？
- 朝7時〜21時までのシフト
- 基本はWebやメール、電話でサポート。将来的にはSlackでサポート
- どんな問い合わせに対応してうる？
- ハウツー系
- SQLサーバーで冗長構成を取りたい
- トラブルシューティング系
- Webサーバー(apacheなど)にうまくつながりません
- ハウツー系
- サポートはナレッジ検索？
- 検索でなんとかなるものは一部だけ
- 検証環境で再現テストをやる
- 社内のリポジトリからコードを持ってきてビルドする
- 問い合わせ以外は？
- ツールの作成
- 開発部門とのやりとり
- 社内外向けにFAQコンテンツ、トレーニングの作成
- まとめ
- 技術サポートもAWSサービスの1つ！
- コツを掴んでうまく使いこなしてください！
AWSサポートの使い方ベストプラクティス 角川 宗近さん
- AWSサポートは技術的なお問い合わせに関するガイドライン | AWS サポートというドキュメントを公開している
- とくに読んでおいてほしい序文
- 「AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。」
- 非効率な例
- 状況把握のためのやりとりの繰り返し
- お客様側が既に試したことを試す
- 問題解決に結びつかないことに時間を使う
- ベストプラクティス
- ガイドラインの想定シナリオ
- 今回の例）深夜の緊急対応、エンドユーザーに影響があり早く解決したい、原因不明、サポートにとりあえず一報した
- (1)解決したい課題を明確にする
- NG：今ELBはメンテナンス中か？
- OK：「ELB名」に外部からアクセスできなくなりました
- (2)経緯を共有する
- NG：色々やっていますがうまくいきません
- OK：xxxxの手順を試しましたが、〜のエラーが出ます
- ガイドラインの想定シナリオ
- 他にも有用な情報がたくさんあるよ！詳しくはこちら
いま、改めてDatabaseとwell-architectedを考えてみる 立野 広樹さん
- フェールオーバーとは？
- フェールオーバーしたら管理者側で何かしなくても再開できる
- あるべき姿
- フェールオーバーして一時的にアプリでエラーが出たけど、その後は問題ないです
- これがW-Aの信頼性の柱
- 失敗する可能性があるものは失敗する
- ダウンタイム0は存在しない
- RDSの可用性もマルチAZで99.9％
- どうすればいい？
- ポイントは回復力。一時的に使えなくなっても自動復旧すること。
- Design For Failure
- 織り込むべきFailure
- いくつかある
- 何が問題で何が回復なのか？
- ユーザーが期待通りの動作をすること、が大切
- 復旧戦略
- ELBでヘルスチェックしてからインスタンス入れ替え
- 毎回接続を作成する
- など、期待通りに動作するか？が大切
- 回復力に対する科学的アプローチ
- 仮説 → 実験 → 検証 → 改善
- W-Aの信頼性の柱で紹介しています！
- RDSには回復力がある
- しかし、システム全体に回復力がある時にしか効果が発揮できない
AWSサポートで見かけた不思議なお問い合わせ 高橋 尚久さん
- 発端
- CloudFront+S3で静的Webサイト
- CloudWatch Syntheticsで1分ごとに監視
- など
- CloudWatch Syntheticsとは？
- スケジュールに沿って設定可能なCanaryを作成し、エンドポイントとAPIをモニタリングできる
- システム構成
- WAF - CloudFront - S3の基本的な構成
- トラブルシューティング
- まずはリクエストIDから調査
- リクエストヘッダーの処理中にエラーが出ていた
- ステータスコード494はヘッダーが大きすぎる場合のエラー
- 標準ログの調査
- 標準ログが2KBを超えていた
- CloudFrontの制限を超えていた、Athenaクエリから確認
- まずはリクエストIDから調査
- この段階での考察
- 4xxエラーなのでリクエスト自体に問題
- UserAgentサイズにより制限に抵触している可能性
- など
- 事象の再現
- お客様環境のCanaryはブループリントから変更している
- 同様のコードを実行すると、User -Agentのサイズが回数に応じて大きくなっていた
- Pythonコードの特有の動きでUser-Agentヘッダーが大きくなるという、おかしな挙動をしていた？
- でもこれでは最大32倍にしかならないので、真の原因ではない
- 追加の原因は、Lambdaのウォームスタートの影響
- まとめ
- LambdaのウォームスタートとPythonのデフォルト引数の挙動でUser-Agentヘッダーのサイズが増加し続けて、CloudFront制限を超えてしまっていた
- 環境を再現して初めてわかることもある
- エラーが発生したサービスだけでなく、幅広い視点を持つことが大切
共著でAWS Glueの本を出しました! 田中 智大さん
- 本題に入る前に…AWS Glueとは？
- データレイクを作成するための最初の処理を行うサービス
- S3などサービスへの接続や、AWS以外のリソースに接続できる
- 今回、共著でGlue本(自称)を出版しました！
- 何が書いてあるの？
- 400ページ
- データとは？Glueとは？から実際のユースケースまでカバー
- Bigデータの使い方
- Glueサービスの使い方
- Glueをどう使っていくのか
- 他サービスとの連携（Lake Formationなど）
- 執筆苦労話
- お誘いいただく
- 契約書サイン
- 執筆開始（頭の中）
- 書いていない
- 執筆開始（怒涛の締切）
- やばい、何も描けてない。1日10ページ書かないといけない
- なんとかチャプター5まで書いた…けど
- 出版社から期限がどんどん提示されて追い込まれる
- 最終的に間に合ったけど、最終締切ギリギリの修正依頼を旅行の道中でiPadから直した（やばい）
- 全体の感想
- やるべきことは早めに進めておこう
- 何事も早く手を動かすことが大切！
- レビュワーの皆様ありがとう！
まとめ
私も日頃からよくお世話になっているAWSサポートの方々による怒涛のLT6連続、迫力がありましたね。
AWSサポートエンジニアの1日の流れから、具体的なトラブルシューティング事例まで盛り沢山な内容でした。
LTを通してAWSサポートの皆様には足を向けて眠れないな、、、とより一層感じた私でした。今後もお世話になります。
以上、AWS事業本部コンサルティング部@東京オフィスの芦沢(＠ashi_ssan)でした。