re:Invent 2023: AWSネットワーク診断・トラブルシューティング必須ツール
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Must-have network diagnostics and troubleshooting tools (NET204)
この動画では、AWSネットワークの診断とトラブルシューティングに関する必須ツールを紹介しています。Amazon VPC、AWS Direct Connect、VPNなどの主要サービスのデバッグ手法や、CloudWatch Internet MonitorやVPC Reachability Analyzerなどの最新ツールの活用法を学べます。また、ネットワークエンジニアの日常で使える実践的なコマンドラインツールや、AWSが社内で実践しているCorrection of Errors（COE）プロセスなど、貴重な知見が満載です。ネットワークの可視化から改善まで、包括的に解説されています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
re:Invent 2023：ネットワーク診断とトラブルシューティングの必須ツール
こんにちは、ラスベガスの皆さん。すごいですね。re:Inventの4日目です。本当に驚きです。今日のセッションにお越しいただき、ありがとうございます。re:Invent 2023の一環として、必須のネットワーク診断とトラブルシューティングツールに関するセッションへようこそ。これは私にとって初めてのre:Inventですが、大勢の方々とリプレイの間に立っていることは承知しています。そのため、このセッションはとても簡潔かつ要点を押さえたものにします。
私はRuskin Dantraと申します。遠く離れたニュージーランドからやってきたSolutions Architectです。私は元々C#、.NET開発者で、型リストがなかった頃から.NETでプログラミングをしています。これは.NET 1.1の時代にさかのぼります。そして、自己紹介をしてくれるEvgenyも一緒です。Evgeny、お願いします。
こんにちは、ラスベガス。私はEvgeny Vaganovです。Specialist SA Leaderで、同じく遠く離れたオーストラリアのシドニーを拠点としています。APJ全域のSpecialist SAチームを率いています。この役職に就く前は、約4年間ネットワーキングSAチームを運営していました。私のブログを読んだことがある方や、以前のre:Inventで見かけた方もいるかもしれません。これは私にとって5回目か6回目のre:Inventです。ですので、決して初めてではありませんが、ここでRuskinに戻して、数分後にまたお会いしましょう。
ありがとう、Evgeny。まず、いくつか注意事項をお伝えします。これは200レベルのセッションです。ネットワーキングツールやサービス、デバッグや診断ツールについて話します。一部の内容では深く掘り下げるかもしれませんが、全体的には200レベルのセッションです。また、写真を撮りたい方のためにスライドにキューを用意しています。さらに、後で参照したり自分のペースで学びたい方のためにQRコードも用意しています。
さて、今日なぜここにいるのか、そしてみなさんがこのセッションに来た理由は何でしょうか？私たちは多くのお客様と話をし、多くの方々と対話を重ね、そこからパターンが浮かび上がってきました。お客様から聞いた一つのことは、AWSのネットワークとネットワーキングサービスが多くの課題を解決してくれるものの、まだブラックボックスのような面があるということです。また、お客様から聞いたもう一つのことは、ネットワークはしばしば責任を押し付けやすいターゲットになっており、その無実を証明するのに数日、時には数週間もかかることがあるということです。そして、私たちは皆、あの有名なネットワーキングの格言「いつもDNSが原因だ」を耳にしたことがあるでしょう。最後に、お客様から聞いたのは、選択肢とオプションは素晴らしいが、ネットワーク診断とツールに関しては、どれを何に使えばいいのかわからないということです。
それでは、今日のセッションのアジェンダを見ていきましょう。まず、問題空間を定義します。今日私たちが解決しようとしている問題を十分に理解したいと思います。次に、ネットワークを観察し可視化する方法をいくつか見ていきます。その後、潜在的な問題の検出と分析、デバッグとトラブルシューティング、根本原因分析の理解、そしてネットワークの改善について見ていきます。最後に、私たちの発見をまとめてセッションを締めくくります。
AWSネットワークの構造と課題
今日の旅に出る前に、このセッションで話し合う内容のメンタルモデルを提示したいと思います。ここにいる私たちのほとんど、もしくは全員がネットワークについて話し合うために来ています。そのため、ネットワーキングがフライホイールの中心にあります。どんな問題でも、観察を通じて 問題を徹底的に理解することが大切です。問題を理解すれば、 問題が発生している最中や、さらには発生する前に、潜在的な問題を事前に検出するのに役立ちます。
問題を検出したら、根本原因分析を行い、問題をデバッグすることができます。これによってネットワークトポロジーを改善することができます。ネットワークトポロジーを改善すると、パフォーマンスが向上し、より多くのユーザーを 獲得でき、最終的にはトラフィックが増加します。これにより、トポロジーをさらに改善するためのパターンをより多く見ることができるようになります。
では、私たちがなぜここにいるのか、もう少し深く掘り下げてみましょう。CTOからこのフレーズを少なくとも100回は聞いたことがあるはずです。「すべてのものは常に故障する」。とてもシンプルで、とても真実で、でも同時にとても不安になる言葉です。準備ができていなければ、ですが。
では、AWSで大規模なネットワークをどのように分散させているか、少し整理してみましょう。ご存知かもしれませんが、私たちにはリージョンとアベイラビリティーゾーンがあります。リージョンは、トランジットセンターとアベイラビリティーゾーンで構成される地理的な中心地です。さらに、アベイラビリティーゾーンは複数のデータセンターで構成されています。このセットアップを理解することが重要です。なぜなら、ネットワークのトラブルシューティングと診断に関しては、ネットワークのどの部分を監視する必要があるか、そしてより重要なのは、ネットワークのどの部分を監視できるかを知ることが重要だからです。
AWSネットワークの複雑性とトラフィックフロー
AWSのリージョンとAvailability Zoneに関する動きを見ていく中で、エンドユーザーからワークロードにトラフィックを届ける方法をいくつか見てみましょう。一つのアプローチは、ワークロードをインターネットに公開することです。もう一つの方法は、CloudFrontディストリビューションやGlobal Acceleratorエンドポイントを利用している場合、エッジロケーションを通じてワークロードを公開することです。
あるいは、広域ネットワークとAWS Direct Connectを通じて、企業のデータセンターユーザーにワークロードを公開することもできます。ユーザーがどのようにワークロードにアクセスするかに関わらず、パケットが発信元から目的地まで辿る過程では、考慮すべき多くのコンポーネントがあります。
インターネットフローについてさらに詳しく見ていきましょう。AWSのワークロードにアクセスするユーザーとして、最初のステップはリクエストをどこに送るかを決定することで、これには名前解決が関わります。次に、そのリクエストをインターネットサービスプロバイダーに送り、その後ピアやインターネットエクスチェンジを経由します。この過程で、プライベートIPアドレスとパブリックIPアドレスの変換を行うネットワークアドレス変換が背後で行われています。さらに、ファイアウォール、アクセスコントロールリスト、侵入検知および防御システムなど、さまざまなセキュリティ対策が機能しています。パケットを発信元から目的地まで追跡する際、問題が発生した場合にそれを推論し、トラブルシューティングする方法を見つける必要があります。Amazon.comのVPおよびCTOであるDr. Werner Vogels氏が有名に述べたように、「すべてのものは常に故障する」のです。
パケットがAWSに入ると、ワークロードに到達できるように相互接続された何百ものデバイスがあります。このインフラストラクチャにより、AWSネットワークに期待されるパフォーマンス、可用性、信頼性を提供することができます。私たちのアンダーレイネットワークは、VPCとして知られるソフトウェア定義ネットワークパラダイムとしてお客様に提示されます。これは複雑に見えるかもしれませんが、問題が発生した際に大規模に診断およびデバッグするための専門知識、ツール、データポイント、メトリクスを私たちは持っています。今日は、この能力をお客様に拡張し、診断の旅をサポートするいくつかのサービスについて説明します。
さらに一段階掘り下げてみましょう。AWSでは、エッジロケーションを使用してできるだけ早くトラフィックをAWSバックボーンにルーティングすることをお勧めしています。トラフィックがAWSに入ると、Availability Zoneに冗長ダークファイバーで接続されたトランジットセンターにリダイレクトされます。AZ内およびAZ間のトラフィックは、Dense Wavelength Division Multiplexing（DWDM）という概念を利用しており、これは複数の光の波長を1本の光ファイバーケーブルに組み合わせます。お客様はこのことを心配する必要はありません。アンダーレイネットワークは、共有責任モデルの一部として完全に抽象化され、管理されています。
このアンダーレイ・ネットワークは抽象化されていますが、今日は皆さんにいくつかの重要な学びを共有したいと思います。何百もの相互接続されたデバイスがある場合、ネットワークのすべての部分やルーターを含めて、ネットワークを十分に活用することが重要です。AWSでは、使用されていないルーターやコンポーネントにフェイルオーバーすることは、私たちの規模では大きなリスクを伴うことを学びました。この原則は、例えばECMPを使用したアクティブ-アクティブVPN接続や、BGPコミュニティを使用したアクティブ-アクティブAWS Direct Connect接続を活用することで、ネットワークトポロジーに適用できます。
また、AWSでは、スペクトルのすべてのレベルにわたってメトリクスを測定することが重要だと学びました。例えば、ネットワークが大半の時間は特定のレイテンシーしきい値内で動作しているが、時々より高いレイテンシーを示す場合、その高いレイテンシーが重要なワークロードやその問題を経験しているユーザーに与える影響を考慮してください。規模が大きくなるにつれてこの問題は悪化するので、スペクトルのすべてのレベルでメトリクスを考慮するようにしてください。最後に、AWSでは、成長だけでなく障害にも対応できるようにネットワークを設計しています。リンクが失敗した場合に何が起こるか、残りのリンクで負荷を処理できるかを考慮してください。できない場合、残りのリンクの連鎖的な障害を経験する可能性があります。
アプリケーション開発者とネットワークエンジニアの視点
AWSネットワークの管理方法についてより深く掘り下げたい方のために、右上にQRコードがあります。Distinguished Engineersによるre:Invent 2018のこのトークを必ずチェックしてください。AWSについて、トラフィックフローについて見てきました。ここで、2人の視点からこれを見てみたいと思います。その前に、会場の皆さんの中でアプリケーション開発者の方がどれくらいいるか確認したいと思います。アプリケーション開発者だと考える方は手を挙げてください。素晴らしい、ありがとうございます。ネットワークエンジニアだと考える方はどれくらいいますか？素晴らしい、良いバランスですね。
では、Sarahを紹介したいと思います。Sarahはアプリケーション開発者です。彼女は要件をソフトウェアに変換します。しかし、皆さんもご存知かもしれませんが、ソフトウェアは必然的にネットワーク上に存在します。SarahはネットワークエンジニアのAlexと会話をします。 Alexはネットワーク上のあらゆるワークロードをサポートするようにしていますが、ご存知の通り、ソフトウェアと要件は頻繁に変更されます。そのため、Alexは変化する要件に合わせてネットワークを適応させる必要があります。Sarahにとっては、彼女の視点はほとんどワークロードからのものです。
Sarahが経験することを見てみましょう。Sarahはプロダクション用のAWSアカウントのSydneyリージョンにワークロードをデプロイしています。Sarahにとって、状況は順調に進んでいます。 彼女は2つ目のワークロードをデプロイします。ここでSarahは、ベストプラクティスではワークロードをデプロイする前にテストすべきだと気づきます。そこで、非プロダクションアカウントに同じワークロードをデプロイします。状況はさらに良くなっています。 次に、彼女はワークロードのデプロイを支援するための自動化パイプラインをデプロイし、Alexに「ねえ、接続を設定してくれない？」と話しかけます。そしてAlexは彼女のためにピアリング接続を設定します。
状況はさらに進展しています。今度は彼女がAWSサービスにアクセスする必要があり、AlexはVPCエンドポイントをいくつか設定し、さらにピアリング接続からAWS Transit Gateway接続に移行します。Alexはこちらの方がスケーラビリティに優れていることを理解しているからです。ここで見てきたように、Sarahの視点は主にワークロード中心です。では、Alexの視点を見てみましょう。
ネットワークトポロジーの成長と課題
Alexにとって、オンプレミスとクラウドの両方にネットワークのフットプリントがあることを認識する必要があります。 Alexの会社の一部のチームは、プロトタイピングのためにデフォルトのVPCにワークロードをデプロイし、Amazon DynamoDBも活用しています。プロトタイピングは順調に進んでいます。彼らはVPCにワークロードをデプロイし、接続性が必要になりました。そこでAlexは彼らのためにピアリングをセットアップします。
別のチームが加わり、さらに別のVPCをデプロイして、Alexに接続性を求めてきました。ここでAlexは頭を抱えています。なぜなら、CIDRアドレスが重複しているからです。そのため、接続性をどのようにセットアップするか、デバッグと診断を行う必要があります。このVPCをセットアップしたチームは、厳しいリリース期限の下にあります。そのため、彼らはワークロードをセットアップし、疑問の余地のある命名規則やルーティング規則、そしてインターネットやAmazon S3バケットへのVPCエンドポイント経由のアクセスなどに対して、かなり緩いセキュリティグループルールを持つセキュリティグループをデプロイしました。企業ユーザーはこのワークロードへのアクセスを必要としています。そこでAlexはVPN接続をセットアップします。
このワークロードは非常に人気があるため、新しいリージョンにデプロイされ、Alexはそれもセットアップし、さらにスケーラビリティを向上させるためにAWS Transit Gatewayもセットアップします。会社自体も順調で、サンフランシスコに新しい支社ができるため、Alexはそのセットアップで忙しくしています。しばらくすると、企業ユーザーはより高速なアクセス速度を求めるようになり、VPNからAWS Direct Connectに移行する必要が出てきます。また、DNS名を使用したより良い体験も要求されているため、Amazon Route 53リゾルバーもセットアップします。
さて、AlexとSarahはかなり忙しくしていましたが、そこには異なる視点があることがわかります。彼らが直面した障害をいくつか見てみましょう。 ご覧の通り、ネットワークトポロジーとネットワークはかなりダイナミックです。要件の変化に応じて有機的に成長し、オンプレミスインフラストラクチャとクラウドインフラストラクチャにまたがって非常に広範囲に及びます。また、ネットワークは多様性に富んでいます。人によって命名規則や経路制御の規則が異なり、オンプレミスインフラとクラウドインフラへのアクセスにも異なるコンソールを使用します。
最後に、すべてのネットワークには何らかのガバナンスが含まれます。すべてのネットワークには目的があり、その目的はネットワークがサポートするワークロードへの契約です。多くの場合、この契約は暗黙的または黙示的なものです。ネットワークが成長するにつれ、これらの契約は部族の知識となり、変更が難しくなり、ネットワークが脆弱になります。では、AlexとSarahがこれらの障害を乗り越えるのに役立つサービス、テクニック、プロセスを見てみましょう。
ネットワークの可視化と観察：ツールとテクニック
先ほどこのフライホイールを見ましたが、まずは観察を通じてネットワークを理解することから始めましょう。ネットワークを観察するには主に3つの側面があります。まず、可視化する必要があります。私は視覚的な学習者で、絵は千の言葉を語ると言いますよね。ネットワークトポロジー、その属性、接続状態を視覚的に表現できれば、戦いの半分は勝ったも同然です。次に、ネットワーク内で何が起こっているかを理解するために、すべてのイベントを捕捉したいと思います。このデータを頻繁かつ広範囲に収集します。最後に、すべてのデータを収集した後、分析とダッシュボードを通じてそれを理解したいと思います。
AWSのネットワークの基本的なブロックであるVPCを可視化する最も簡単な方法は、AWSコンソールのリソースマップビューを使用することです。これは今すぐ利用可能です。この例では、私のVPCに4つのルートテーブルで消費されるS3エンドポイントがあり、そのルートテーブルが4つのサブネットに関連付けられていることがすぐにわかります。また、AWS Network Managerを使用してネットワークトポロジーを可視化することもできます。AWS Network Managerには、AWS Cloud WANを使用してコアネットワークエッジを自動管理する場合、またはAWS Transit GatewayやTransit Gatewayピアリングを使用する場合の2つのオプションがあります。
Alexが Cloud WANを使用している場合、どのように可視化するかをもう少し詳しく見てみましょう。この例では、Alexは Cloud WANをセットアップし、Oregon、Singapore、Sydneyの3つのリージョンでコアネットワークエッジを管理しています。また、AucklandオフィスからVPNが来て、Sydneyのコアネットワークエッジに接続されています。この論理的な表現がNetwork Managerでどのように表されるかを示す、とてもクールなアニメーションが表示されるので、画面にご注目ください。これで、AlexはNetwork Manager自体で、ネットワークトポロジーがどのようにセットアップされているかを全体的に把握できるようになりました。
例えば、Alexが Transit Gateway と Transit Gateway ピアリングを活用していたとしましょう。これも同様の方法で機能します。ここでも、Alexは3つのリージョンにまたがって Transit Gateway を設定しています。ピアリングを行い、オークランドとサンフランシスコに2つのVPN接続を持っています。これをNetwork Managerで可視化すると、このような表示になります。ここでもAlexはネットワークの全体像を把握できます。オレンジの線が Transit Gateway ピアリング接続を、緑の線が機能しているVPN接続を表していることに注目してください。例えば、VPN接続に何か問題が発生したとします。Alexは視覚的な手がかりによって、VPN接続に問題があることをすぐに通知されます。さらに詳しく調べることで、VPN接続の一部であるトンネルの1つがダウンしていることがわかります。
ここまでAWSコンポーネントが画面上でどのように表示されるかを説明しましたが、Alexがオンプレミスのコンポーネントをネットワークトポロジーのグラフや地図に表示させる方法についてはまだ説明していませんでした。そのために、AlexはNetwork Managerのデバイスとサイトを活用しました。Alexはまず、オンプレミスのネットワーク位置を表すサイトを設定します。次に、デバイスを設定してそれをサイトに関連付け、最後にカスタマーゲートウェイとの関連付けを行います。Alexはここでかなり賢明な選択をしています。これらの作業はすべてコンソールで行えますが、変化するニーズに対応するには自動化が必要だと気づきました。そのため、AWS CLIを使ってこれらの作業をすべて行うこともできるのです。
AlexとSarahがネットワークトポロジーを可視化したところで、次はログを通じてネットワークトラフィックの流れを可視化することに焦点を移しました。SarahはVPCにワークロードをデプロイしました。そして、AlexとSarahはログの収集を開始しました。トラフィックフローのメタデータを取得するためにVPC Flow Logsを収集し、昨年半ばからTransit Gatewayからもフローログを収集しています。ネットワークの全体像を把握するために、ロードバランサー、ファイアウォール、Route 53からもフローログを収集することをお勧めします。
これらのログを収集したら、それらを保存する方法が必要になります。AWSにはここでもいくつかのオプションがあります。Amazon CloudWatch Logsを使用してログを保存し、クエリを実行し、ダッシュボードに組み込むことができます。長期保存を低コストで行いたい場合はAmazon S3を使用し、サードパーティ製品と統合したい場合はAmazon Kinesis Data Firehoseを活用できます。
ログを保存したら、それらを分析する方法が必要です。AWSはこの目的のためにいくつかのオプションを提供しています。Amazon Managed Service for GrafanaやAmazon OpenSearchなど、AmazonのOpenSearch製品を使用できます。また、Amazon CloudWatchダッシュボードやAmazon QuickSightを使用してプロットしたり、必要に応じてAmazon Athenaを使用してログに直接クエリを実行したりすることもできます。
ダッシュボードと言えば、まだ始めていない方には CloudWatch の自動ダッシュボード機能の使用を強くお勧めします。この機能を使えば、手動で設定することなく、メトリクスのダッシュボードを素早くセットアップできます。ここでは、Transit Gateway と NAT gateway 用に私が素早くセットアップしたダッシュボードの例をご覧いただけます。CloudWatch はクロスリージョンやクロスアカウントのダッシュボードもサポートしているので、分散型のネットワークトポロジーも可視化できます。
VPCフローログの活用とContributor Insightsの導入
考慮すべきもう一つのオプションは、異なるユーザーや貢献者がネットワークフローにどのような影響を与えるかということです。例えば、貢献者が PrivateLink エンドポイントをどのように使用しているかを知りたい場合、 Contributor Insights を使用できます。セットアップは3つの簡単なステップで行えます。まず、使用するログを特定します。この場合、VPC フローログを使用します。次に、VPC フローログから関心のあるフィールドを定義し、貢献者を作成するのに十分にユニークな2つのキーを指定します。最後に、必要なフィルターを追加します。例えば、 VPC エンドポイントを3つのアベイラビリティーゾーンにデプロイした場合、その3つの ENI にのみ興味があるかもしれません。これが基本的に私がここで行ったことです。また、合計や数などの集計を指定することもできます。
結果として、ここに示すようなダッシュボードが得られます。これで、Alex と Sarah は誰が PrivateLink エンドポイントに最もアクセスしているかを正確に把握できます。このグラフから、.87 上のインスタンスが PrivateLink エンドポイントに頻繁にアクセスしていることがわかります。そのため、Alex がその特定の PrivateLink エンドポイントのトラブルシューティングや診断を行う必要がある場合、そのインスタンスで実行されている Sarah のワークロードが影響を受けることがわかるでしょう。
次に、Amazon QuickSight を使用して VPC フローログを可視化する例を紹介します。この例では、あるお客様のコスト関連の質問を理解し、回答するのを手伝っていました。お客様は、1つのアベイラビリティーゾーンにのみデプロイされたネットワークトポロジーに対して、クロス AZ コストとして表示される異常なコストを確認していました。さらに調査を進めた結果、 ワークロードがパブリック IPv4 アドレスを使用して EC2 リソースにアクセスしており、それが計測の原因となっていることがわかりました。ご覧のように、トポロジーを可視化し、ログを理解することで、問題をより迅速に検出できます。
Observe セクションのまとめとして、3つの重要なリソースを共有したいと思います。1つ目は、Contributor Insights とダッシュボードを作成するための CloudFormation テンプレートを含む GitHub リポジトリです。2つ目は、VPC フローログ用の Amazon QuickSight ダッシュボードのセットアップをステップバイステップでガイドするワークショップです。最後に、Cost and Usage Report データを使用してトラフィックパターンを理解するための Athena クエリの全ライブラリがあります。
問題検出：アラート、CloudWatch Internet Monitor、VPC Reachability Analyzer
さて、AlexとSarahがネットワークについてよく理解できたところで、潜在的な問題を検出する方法を見ていきましょう。トラブルシューティングやデバッグを始める前に、まず何かが起きていることを知らせる必要があります。 AlexとSarahが通知を受け取る方法は3つあります。皆さんも経験したことがあるかもしれませんが、ユーザーが肩をたたいてワークロードやネットワークのパフォーマンスが悪いと報告してくる、アラームが発生する、異常検出が問題を指摘する、といったものです。
アラートが発生したら、Amazon EventBridgeを使って複数のチャンネルに通知を配信できます。これによって、 AlexとSarahは問題の調査を開始します。Personal Health Dashboard、CloudWatchダッシュボード、QuickSightダッシュボードなどを確認したり、Athenaを使ってクエリを実行したり、AWS CloudTrailを使って問題を確認したりすることができます。
アラームと言えば、10月にCloudWatch recommended alarmsをリリースしました。この機能を使えば、AWS管理メトリクスに対してAWSのベストプラクティスを用いたアラームを素早く作成できます。実際にはどういうことでしょうか？先ほどの例で、AlexがVPN接続やいずれかのVPN接続でトンネルが失われた時に通知を受けたいと考えていたのを覚えていますか。
Alexはrecommended alarmsを使って、そのようなアラームを素早く設定できます。コンソールから直接設定するか、Infrastructure as Codeを使用することができます。 コンソールを使う場合、いくつかのフィールドが既に入力されていることに注目してください。そのため、どのようなメトリクスやしきい値を設定すべきか悩む必要はありません。Infrastructure as Codeを使用する場合も、ほとんど、あるいはすべてのフィールドが自動的に入力されていることがわかります。 このコードをコピーして自動化スイートに貼り付けるだけでOKです。
次に、AlexとSarahは、インターネット経由でワークロードにアクセスするユーザーの問題をどのように検出できるかに注目します。 このために、AmazonにはAmazon CloudWatch Internet Monitorがあります。これを使えば、インターネットの状況がワークロードやエンドユーザーエクスペリエンスにどのような影響を与えているかを理解できます。先ほど、AWSには多数のエッジロケーションとトランジットセンターがあり、インターネットからワークロードが存在するリージョンまでトラフィックを運ぶことができると説明しました。AWSネットワークに期待される可用性、パフォーマンス、信頼性を確保するため、私たちはこれらを監視しています。そして、この監視データがCloudWatch Internet Monitorで活用されているのです。
インターネットモニターをセットアップすると、インターネットのどの部分がワークロードが存在するリージョンと通信しているかを把握し、積極的にモニタリングすることができます。パフォーマンスと可用性のベースラインを確立し、ユーザーがワークロードにアクセスする際に特定の問題を経験している場合、健全性メトリクスと共に認識を作成します。これにより、AlexとSarahは必要に応じて事前に対策を講じることができます。例えば、潜在的にボトルネックとなっているインターネットサービスプロバイダーを回避するために、ワークロード全体を新しいリージョンにデプロイすることができます。
もう少し詳しく見てみましょう。インターネットモニターはどのように機能するのでしょうか？ 4つの主要なコンポーネントで構成されています。まず、ネットワークのどの部分がインターネットトラフィックを受信しているかをインターネットモニターに伝える必要があります。現在、Amazon VPC、Network Load Balancer、CloudFront distribution、Amazon WorkSpacesをサポートしています。次に、モニタリングしたいトラフィックの割合を指定します。そして、私たちが行うのは、トランジットセンターとエッジロケーションについてすでに収集したデータをオーバーレイすることです。最終的に、コンソール上で一連の最適化を提供します。
ダッシュボードの観点からはどのように見えるでしょうか？AlexとSarahはこのビューを得ます。このビューから、午前9時から午後1時までの間、ユーザーがインターネットからワークロードにアクセスする際に問題があったことをすぐに確認できます。さらに詳しく見ると、転送されたバイト数とラウンドトリップ時間も影響を受けていたことがわかります。そして下部を見ると、スペクトルのすべてのレベルでメトリクスを提供しています。P-95からP-50まで全てです。最後に、AlexとSarahはさらに掘り下げて、特定の場所がどのように影響を受けたか、その場所でどれだけのトラフィックが影響を受けたか、そしてユーザーがどのように影響を受けたかを確認できます。
Network Access Analyzerとデバッグのメンタルモデル
インターネット全体の問題をAlexとSarahが検出するのを支援する方法を理解したところで、AWS自体の問題を検出するのを支援することに焦点を移しましょう。そのために3つの主要なサービスがあります。VPC Reachability Analyzerは、Alexがソースが宛先と通信できるかどうかを確認できるようにします。また、Transit Gateway Route Analyzerもあり、これはトランジットゲートウェイルートテーブル内のルーティングを検証することができます。そしてNetwork Access Analyzerは、Alexがネットワークトポロジー全体にわたる意図しないネットワークアクセスを理解し、修正することを可能にします。
Reachability Analyzerを使用することで、Alexは例えばVPCピアリングを介してあるインスタンスが別のインスタンスと通信できることを素早く証明できます。また、トランジットゲートウェイアタッチメントを使用して同じことが可能であることも証明できます。さらに、ネットワークファイアウォールが設置されていても通信が機能することも証明できます。右側を見ると、Reachability Analyzerは中間コンポーネントを考慮に入れて、その通信が行われている際にネットワークファイアウォールのどのルールグループが行使されたかもAlexに伝えています。ネットワークにはさまざまな形態があることは承知していますので、Reachability Analyzerがあなたのフローにどのように対応するかを理解するために、必ずドキュメントを参照してください。
さて、2点間の接続を確認する方法についてAlexを助けましたが、Sarahの助けにもなるでしょうか？Amazon Qの最新リリースにより、Sarahは自然言語で簡単な人間らしい質問をすることができるようになりました。そして、接続性を確認する方法を理解できるようになりました。Sarahがネットワークトラブルシューティングに関連する質問をすると、次のスライドで見るようなプレビュー体験が提供されることがよくあります。ここで注意点として、これは北バージニアリージョンでのみ利用可能です。テストする際は、適切なリージョンを選択してください。
Sarahは今、Amazon Q network troubleshootingに行き、「ロードバランサー上で動作しているアプリケーションにパブリックからアクセスできますか？」と尋ねることができます。Amazon Q for network troubleshootingは、この質問を単純に解釈し、Sarahの意図を明確に捉えたことを確認するために再表示します。そして、画面に表示されているように、実際にSarahのために分析を実行します。Sarahがする必要があったのは質問を入力するだけで、最後には結果も要約してくれます。とてもクールなので、ぜひこのサービスを試してみて、フィードバックをお寄せください。ありがたく思います。
最後に、Reachability Analyzerについてですが、VPC Reachability Analyzerを使用すると、ポイントツーポイントの通信を確認できます。Network Access AnalyzerはAlexが意図しないネットワークアクセスを証明するのに役立ちます。つまり、この例では、Alexはネットワークファイアウォールを経由しないでインターネットに出ていくエグレストラフィックがないことを確認したいのです。彼がする必要があるのは、Network Access Analyzerにアクセス要件を伝えることだけです。最初のステップとして、リソースを選択する必要があります。この場合、ソースとしてVPCを、宛先としてインターネットゲートウェイを設定します。
次に、Network Access Analyzerに対して、意図したアクセス、つまり本質的にネットワークファイアウォールを経由するアクセスについての検出結果やネットワークアクセスは気にしないことを伝える必要があります。そこで、いくつかの除外設定を行います。ネットワークファイアウォールを経由するトラフィックは報告しないように指示します。Access Analyzerは自動推論を使用して、そのルールが違反された場合にAlexに検出結果を表示します。この場合、Alexは非常に満足しています。VPCのどの部分もネットワークファイアウォールを経由しないエグレストラフィックはありません。
これで検出セッションは終了ですが、ここでいくつかのリソースをご紹介したいと思います。最初のリソースは、Personal Health Dashboardをセットアップし、さまざまなアラートチャンネルを設定するのに役立つブログです。次に、VPCのさまざまなシナリオに対して異なるアナライザーを実行できるワークショップがあります。最後に、Internet Monitorの仕組みに興味がある方は、ドキュメントで詳しく説明されています。それでは、セッションの残りの部分はEvgenyに引き継ぎたいと思います。
ネットワークデバッグ：TCP/IPモデルとDirect Connectのトラブルシューティング
ありがとう、Ruskin。拍手をお願いします。30分で55枚ものスライドを見てきましたからね。さて、これでネットワークの可視化と問題の検出ができるようになりました。次はネットワークのデバッグについて話しましょう。効率的かつ迅速にデバッグするためには、メンタルモデルが必要です。私が20年近く使ってきて、とても役立ってきたメンタルモデルは、アプリケーションとネットワークを層で考えることです。これは、子供の頃や子供と一緒に遊んだことがあるかもしれないジェンガのゲームのようなものです。アプリケーションがその塔の一番上の層で、その下のすべての層が私たちのネットワークだと考えてください。アプリケーションの下の層で何か起こると、その上のすべてに影響が及びます。
使用できるそのようなモデルの1つが、TCP/IPの概念モデルです。一番下にネットワーク層があります。ネットワーク層は、ビットを線路上で送信することに関わっています。ここでは、MACアドレス、VLAN、ファイバーなどの用語が出てきます。そして、この層でAWS Direct Connectのようなサービスを考えることができます。その上にインターネット層があります。ここでは、IPアドレッシングやルーティングなどが問題になります。Amazon VPCは、AWSが管理するネットワーク層の上で動作するソフトウェア定義ネットワークです。AWS Direct ConnectもIPアドレッシングを持っているので、複数の層にまたがっているといえます。
その上にトランスポート層があります。トランスポート層は、TCPやUDPなどのプロトコルやポート定義に関係しています。ここでAWS Network Firewallのようなネットワークサービスを使用してトラフィックをフィルタリングし始めることができます。最後に、その上にアプリケーション層があり、これはSarahの領域です。アプリケーション層では、ロードバランサーのリスナーにロードされたTLS証明書による暗号化の設定や、実際のアプリケーションの実行などを行います。
トラブルシューティングの例を見ていきましょう。各層を順に見ていき、どのように展開されるかの例をお見せします。まずはDirect Connectのトラブルシューティングから始めましょう。Direct Connectに問題がある場合、ネットワーク層をどのようにトラブルシューティングするのでしょうか？Direct Connectのトラブルシューティングは、おそらくAlexの領域でしょう。Sarahがここに関わることはあまりないでしょう。
通常、Alexが管理するルーターからAWSが管理するルーターへのファイバーがあります。Direct Connectの場所と同じデータセンターにいる場合は直接ファイバーを接続するかもしれませんし、中間にパートナーを使用するかもしれません。物理接続を使用している場合、どこかでスイッチのポートに物理的なファイバーを接続する必要があります。ここで問題が発生する可能性があります。そのポートに光が通っていない、接続がダウンしている、あるいは光は通っているが良好な範囲外である可能性があります。または、光の範囲は良好でも、MACアドレスがARPテーブルに登録されていない可能性もあります。
ここでは全てのトラブルシューティングの手順を説明するわけではありませんが、接続テストを行ったり、テスターで光レベルをチェックしたり、データセンターのスタッフに協力を求めたりすることができます。インフラを管理してもらっている場合は特にそうです。時には光ファイバーのストランドが単に汚れているだけで、少し清掃が必要な場合もあります。Alexの場合は、ルーターにログインしてARPテーブルをチェックし、MACアドレスが表示されているかどうかを確認することもできます。Direct Connectのネットワーク層に関する詳細なトラブルシューティング手順については、QRコードの先にある記事をチェックしてください。
トラブルシューティングでは、ダッシュボードやCloudWatchメトリクスを活用できます。最初に役立つメトリクスは接続状態で、これを見れば接続が up か down かをすぐに確認できます。理想的には、Ruskinが話していた推奨アラームを使って事前にアラームを設定しておくことですが、その場でログインしてメトリクスをチェックしてデバッグすることもできます。光レベルなども確認できます。ここに示されているのは、ドキュメントに記載されている適正範囲です。できればこの範囲内であることが望ましいですが、範囲外の場合は問題があることを示しています。おそらく埃や途中のファイバーの不具合などが原因でしょう。
では、Jengaタワーを1段上がって、インターネット層に移りましょう。実は、私ならここから始めます。必ずしも最初に接続が up か down かを見るわけではありません。タワーの中間から始めて、上下のレイヤーのどちらに進むべきかを判断する方が効率的です。これはずっと速く、はるかに効率的です。では、ここでは通常どのようにチェックするのでしょうか？ほとんどの方がよくご存じのpingというツールを使います。実際、多くの方は定期的にpingリクエストを送信するモニタリングソフトウェアを実行しているはずです。これはICMPパケットを使用します。これにより、ダウンタイムやパケットロス、その他の中間的なイベントを非常に素早く検出できます。
VPNとアプリケーションレベルのトラブルシューティング
Direct Connectでは、接続の相手側のIPアドレスに対して単純にpingを実行し、応答があるかどうかを確認できます。応答がある場合は、さらにトラブルシューティングを続けて、BGPが up しているかどうかを確認します。BGPはBorder Gateway Protocolの略で、IPネットワーク上でルーティング情報を交換するために使用します。Direct Connectではこれを使用します。VPNでも使用でき、これはAlexが外部との接続を行う際の基本中の基本です。ここでの一例として、Alexはアクセス権のあるルーターにログインして、一連のデバッグコマンドを実行できます。繰り返しになりますが、詳しい方法を知りたい場合は、QRコードをスキャンすることをお勧めします。そこには詳細な手順が記載された記事があります。
お客様がDirect Connectの上やインターネットの上でVPN接続を実行することも珍しくありません。これにより暗号化されたトンネルが得られるので、多くのお客様がVPNを利用しているのを見かけます。VPNはデバッグやトラブルシューティングが非常に難しいことで有名です。私も昔、ポケベルを持ち歩いてオンコール対応をしていた頃は、VPNのトラブルシューティングに相当な時間を費やしました。
VPNを使用する場合、ログを活用して問題のトラブルシューティングを行うことができます。基本的な接続が確立され、トンネルの反対側にpingが通るようになったら、AWS側でVPNログを一時的に有効にすることができます。また、Customer Gateway (CGW)側からもログを取得できます。VPNのネゴシエーションがフェーズを経ていく中で、両方のログを並べて比較すると非常に役立つことがあります。これらのログを順を追って確認することで、どの時点で失敗したかを特定し、設定ミスやパケットのブロッキングの問題についての手がかりを得ることができます。
基本的な接続が確立されたと仮定すると、次にアプリケーションにアクセスできるかどうかを確認します。pingも引き続き使えますが、さらに一歩進んで、いわゆるTCP pingを送信するツールを使用することをお勧めします。これらのツールはSYNパケットを送信して応答を待ち、本質的にTCPハンドシェイクを利用して接続性を確認します。その一例がhping3です。同様の機能を持つツールは他にもいくつかありますが、これはアプリケーションが実際に応答しているかどうかを確認します。ICMPがブロックされていることもあるので、ping応答がないからといって必ずしも接続がないわけではありません。TCP pingは間違いなくツールボックスに入れておくべき必須ツールです。
もう一つ便利なツールはncまたはnetcatで、これもTCP pingに相当するものを送信したり、他のいくつかの機能を実行したりできます。DNSも確認したい項目の一つです。基本的なIP接続はできているのに、ユーザーがDNS名を解決できないだけかもしれません。ここでdigやnslookupといったツールが検証に役立ちます。また、クエリログなど、有効にしているログがあればそれも確認できます。
次のスライドでは、私の必須IPネットワークツールボックスについてご紹介します。これらは長年使い続けているツールで、今でも重宝しています。ネットワークがどんなに高度になっても、トラブルシューティングにはこれらの基本的なツールを使い続けています。Netcatは非常に便利です。アプリケーションにアクセスできないことが多いのですが、誰かが「ポート8080でリッスンする必要がある」と言ってきたら、netcatを使って簡単なリスナーを自分で設定し、クライアントとしてもう一方でnetcatを使ってパケットを送信し、接続が成功したかどうかを確認できます。これはネットワークやインターネットトランスポートからアプリケーション層まで、すべてのレイヤーをテストします。非常にシンプルで軽量なツールで、セットアップにはt2.microやt4のEC2 Linuxインスタンスがあれば十分です。
必須IPネットワークツールボックスとその活用法
DNSネットワークのトラブルシューティングには、digが私の選択するツールです。WindowsとLinuxの両方で動作するnslookupもあります。これらのツールを使ったことがない方は、ぜひ今後2週間のうちに1時間ほど時間を取って学んでみることをお勧めします。私は長年これらを使っていて、おそらく2週間に1回くらいの頻度で、ドメイン名が何に解決されるかを調べたり、誰かが問題を報告したときにAWSでホストされているかどうかを確認したりしています。digやnslookupは、IPv4のホスト名からIPアドレスへのマッピングを示すAレコードや、IPv6用のAAAAレコードなど、さまざまなタイプのDNSレコードを解決できます。最近はIPv6ネットワークをよく目にするようになったので、どのツールがIPv6をサポートしているか、そしてそれらがどのように機能するかを知っておくことは重要です。例えば、IPv6アドレスにpingを打つには通常のpingではなく、ping6を使う必要があります。これは、初めてIPv6ネットワークに遭遇してトラブルシューティングやデバッグを行う必要がある人々を悩ませる点です。
もう一つ言及する価値のあるツールは iPerf です。このツールの使い方を確認できる QR コードを用意しました。iPerf を使えば、ネットワーク上の2つのエンドポイント間で達成可能な最大帯域幅を測定できます。アプリケーションが期待通りのパフォーマンスを出せない時、2つの EC2 インスタンス間の帯域幅をどうやってテストし証明すればいいのかとよく聞かれます。iPerf はそういった場面で非常に役立ちます。一方の EC2 インスタンスでリスナーサーバーモードに設定し、もう一方の EC2 インスタンスやオンプレミスのネットワーク内でクライアントとして設定して、合成トラフィックを送信し始めることができます。
送信したいフローの数や、TCP か UDP かを指定して、ネットワーク越しに送信できます。例を挙げると、400 ギガビットインスタンスのテストをしていました。これらが最初に登場した時、4つのネットワークインターフェースカードが付いていて、1つのインスタンスから別のインスタンスへ簡単に400ギガビットを実現できることを証明したいと思いました。
そのために、EC2 プレイスメントグループにインスタンスを配置しました。4つのネットワークインターフェースカードすべてが利用されるよう、iPerf をそれらすべてにバインドしました。iPerf コマンドの定義で少なくとも10のネットワークフローを使用する必要がありました。なぜでしょうか？プレイスメントグループ内では、単一の TCP フローのトラフィックを10ギガビットに制限していて、プレイスメントグループ外では5ギガビットに制限していたからです。現在は CNA express を使用すれば、インスタンスがサポートしている場合はより高速になります。私たちはそれを利用して、単一フローで10ギガビットまで引き上げました。こうして、2つのインスタンス間で400ギガビットのスループットを簡単に実現できることを証明できました。
最後に紹介したいツールは tcpdump です。他の方法がすべて失敗した時、パケットキャプチャに頼ることになります。通常、送信元と宛先で同時にパケットキャプチャを行います。Wireshark というツールを使ってパケットキャプチャをインポートできます。これは GUI ツールで、TCP ストリームの追跡などのトラブルシューティングに役立ちます。フィルターやその他の便利な機能も備えています。コマンドラインインターフェース内で出力を確認することもできます。パケットが送信され、相手側で受信されているか、送信者側で応答を受信しているかなど、基本的な情報を確認するのに便利です。
では、これが私のスターターツールボックスです。全体としてどのように組み合わさるのでしょうか？まず、インターネット層から始めます。通常、Reachability Analyzerを使用するなど、基本的なトラブルシューティングを行います。Amazon Qを使用したり、ダッシュボード、メトリクスなどを確認したりします。この時点で問題が解決しない場合は、一層下がってネットワークのトラブルシューティングを始める必要があるかもしれません。そこで問題がなければ、一層上がってアプリケーションに接続できるかどうかを確認します。セキュリティグループの設定ミスやネットワークファイアウォールが邪魔をしている可能性があります。ここでNetwork Access Analyzerを使用できます。トラフィックミラーリングを設定したり、ソースでtcpdumpを実行したりすることもできます。
最後に、アプリケーション層では、かなり多くのツールがあります。実際、アプリケーション層内でトラブルシューティングやデバッグを行うための方法を議論するだけでも、少なくとも1時間はかかるでしょう。アプリケーションをデバッグしたり、ネットワークの背景からデバッグについて学びたい場合は、ワークショップのQRコードがあります。自分のペースで進められ、AWSのアプリケーション内でのトレーシングなどの可観測性テクニックについて学べます。ぜひチェックしてみてください。
AWS Supportの活用とネットワーク改善のアプローチ
ツールやダッシュボード、アラームをいくつ持っていても、時には選択肢が尽きたように感じることがあります。そのような状況に陥った場合は、躊躇せずにAWS Supportに連絡してください。AWSのネットワークとその上で動作するアプリケーションの両方に精通した、非常に経験豊富なエンジニアが対応してくれます。実際、あなたの組織はおそらくすでにAWS Supportの何らかのティアに対して支払いをしているはずです。ですので、一回限りのデバッグだけでなく、ネットワークを改善するための提案も求めるなど、彼らを活用してください。
改善の話が出たところで、このプレゼンテーションの最後の部分に移りましょう。先ほどRuskinが、アプリケーションへのインターネット接続を監視できるCloudWatch Internet Monitorについて言及しました。Internet Monitor内には、トラフィック最適化と呼ばれるものがあります。トラフィック最適化が行うのは、世界中の異なる地理的エリアからあなたのリージョンに送信されるトラフィック量の観点から、トラフィックプロファイルがどのように見えるかを示すことです。また、提案も行います。アプリケーションを複数のリージョンで立ち上げた場合、最初のバイトまでの時間（TTFB）はどうなるでしょうか？ここでハイライトされているように、アプリケーションをUS East 1 North Virginiaリージョンだけでなく、米国西海岸のUS West 1にも設置した場合、レイテンシーがほぼ半分になることがわかります。これは、最初のバイトのレイテンシーの観点から見ると、大幅な改善です。ウェブアプリケーションを運用している場合、
「Show us CloudFront improvements」をクリックするだけで、CloudFrontを有効にした場合、世界中の異なる場所からの初回バイトレイテンシーがどのようになるかを確認できます。ご覧のように、世界中で大幅に低いレイテンシーが見られ、この具体例では112ミリ秒から25-30ミリ秒まで下がっています。これは、チームの人々にCloudFrontを導入する説得をする際に活用できる大きな改善点です。
ネットワークを改善するもう一つの方法は、障害を体系的に分析し、ネットワークの変更や改善を実施するためのアクションアイテムを作成することです。Amazonでは、この方法を多用しています。Correction of Errors（COE）と呼ばれるメカニズムを厳密に遵守しています。COEは、顧客に影響を与えるイベントの構造化された分析です。
この構造は、要約と影響から始まり、何が起こったのか、いつ起こったのか、なぜ起こったのかを問います。正確なタイムラインを提供し、イベントがいつ始まり、いつ終わったか、そしてその間に起こったすべてのイベントを記録します。メトリクスとグラフも提供します。実際、メトリクスとグラフがなく、COEに追加できない場合、それ自体が大きな警告信号となります。そのため、最初のアクションアイテムは、将来このような影響を確認できるようにアラームとグラフを作成することです。
また、Toyotaの「5つのなぜ」アプローチも活用しています。これはToyotaが製造品質の向上のために導入し活用したもので、IT業界にも適用可能です。私たちはこれを使って、もはや「なぜ」という質問ができなくなるまで自問自答します。これにより、問題の究極の根本原因にたどり着き、それを修正することができます。最後に、アクションアイテムのリストがあります。COEを作成する過程で、アクションアイテムが作成され、担当者が割り当てられ、ネットワークを改善するために順次実行されます。詳しく知りたい方は、このQRコードにリンクされた当社のプリンシパルエンジニアによるトークをご覧ください。彼女がこのプロセスを使ってネットワークを改善する方法を詳しく説明しています。
Amazon VPC Latticeとネットワーキングコアコース
ネットワークを改善するもう一つの方法は、AWSで利用可能な他のサービスを確認することです。AWSでは、お客様の声に耳を傾け、アプリケーションのデプロイと運用を簡素化する新しいサービスや機能を作成しています。そのようなサービスの一つが、前回のre:Inventで発表したAmazon VPC Latticeです。これにより、VPCピアリングを作成したり、transit gatewayのようなものを利用したりすることなく、VPC間の接続を安全かつシンプルに行うことができます。
VPC Latticeを使用すると、アプリケーションコンポーネント間のトラフィックの認証と認可を可能にするアイデンティティとアクセス管理ポリシーを使用して、コンポーネントを接続できます。コンピューティングとネットワークのスケーリングなどが組み込まれたトラフィック管理とスケーリングを行うことができ、HTTP、HTTPS、gRPCプロトコルがサポートされています。これにより、コンテナ、EC2インスタンス、Lambda関数などのサービスをVPCを接続することなく、シームレスに単一のサービスネットワークに接続できます。
VPC Latticeには、IPアドレスの重複に対する対策が組み込まれており、重複するネットワークや、IPv4空間からIPv6への接続も可能です。すべてがVPC Latticeに組み込まれており、シームレスに解決してくれます。これは、Sarahがネットワークを非常に簡単に運用し、Alexに頻繁に頼る必要がなくなるのに役立つでしょう。VPC Latticeについてもっと詳しく知りたい場合は、QRコードをスキャンして追加情報をご覧ください。
今日は多くの異なるサービスについて話しましたが、全体像を網羅しようとすると、どれか1つに深く踏み込むことはできません。今年の初めに、自分のペースで学べるオンラインコースであるネットワーキングコアコースを導入しました。このコースは完全に無料で、最後にテストを受けてAWSネットワーキングの基礎知識を確認するデジタルバッジを取得できます。今日話したサービスやその他のサービスについてもっと知りたい方は、ぜひこのコースをチェックしてみてください。
セッションのまとめと今後の展望
ここで、主要なポイントを振り返ってみましょう。まず、既存のツールを使用してネットワークを理解し、観察・可視化する方法について話しました。ログの重要性、ネットワーク上の問題を簡単に観察・検出するためのアラームとダッシュボードの設定について議論しました。TCP/IP概念モデルを使用して、SarahとAlexの両方がネットワーク上の問題を効率的かつ効果的にデバッグし、 問題の発生場所を特定するために使用できるさまざまなツールについて説明しました。
また、AWSネットワークはブラックボックスではないということも話しました。ネットワークの可視性を提供する多くのツールがあり、それらを活用できますが、行き詰まった場合はAWS Supportに相談することもできます。最後に、ネットワーク上の障害を活用して継続的な改善とイノベーションを推進し、ネットワークトポロジーを改善することについて話しました。これにより、パフォーマンスが向上し、より多くのユーザーを獲得でき、最終的にはネットワーク上でホストされるアプリケーションのトラフィックと成功につながります。
最後になりましたが、午後5時近くまでここにいてくださった皆様に感謝申し上げます。本当に感心しました。ぜひ私たちとつながってください。画面に連絡先の詳細を表示しておきます。そして、このアンケートにぜひご回答ください。特に今週初めのネットワーキングセッションに参加しようとしたけれど入れなかった方や、断られてしまった方は、ぜひご回答をお願いします。このアンケートは、今後のイベントを改善し、皆様が最も好むセッションにより大きな会場を用意するために非常に重要です。以上で終わります。ありがとうございました。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion