Amazon Qでトラブルシューティングしてみた【和訳付き】 - 弥生開発者ブログ

Amazon Qでトラブルシューティングしてみた【和訳付き】

AWS

この記事は弥生 Advent Calendar 2023 の24日目のエントリーです。

はじめに

こんにちは。弥生株式会社の田邊です。普段はサービス開発チームのアプリケーションエンジニアをしています。 今年の11月末にアメリカのラスベガスでAWS re:Invent2023に現地参加し、AWSへのモチベーションが高まりました。

（どれくらい高まったかは先日私が執筆した↓の記事をご覧ください） tech-blog.yayoi-kk.co.jp

AWS re:Invent2023でNew Launchとして発表されたサービスはたくさんありましたが、その中で私が着目したのはAmazon Qです。

KeynoteでのAmazon Qの発表の様子

AWSを使う開発者にとってかなり便利そうなサービスなので、今回はどの程度使えるのものなのかを実際に触って確認してみました。

Amazon Q

Amazon Qとは、生成AIを活用した業務向けのアシスタントサービスです。今話題になっているChatGPTやCopilotなどと競合するサービスです。 応答形式の会話やチャットボット連携、ソースコードの変換サポートなど様々な機能がありますが、私が特に気になったのはトラブルシューティングの補佐です。

AWSでの開発を行っていると、少しの設定ミスでアプリケーションが動かなくなることは少なくありません。そのようなケースの場合、大抵は発生したエラーから原因を予測し、設定を見直すことになります。 しかし、十分に成熟した開発者でなければ、原因をすぐに特定することは簡単ではありません。 私がAmazon Qについての発表を聞いたときに思ったのは、「Amazon Qを使えば、トラブル発生時の原因特定が簡単になるのでは！？」ということでした。 しかし、本当にそれほど上手くいくのか、実際に触って検証してみることにしました。

触ってみた

実際に業務支援Amazon Qのチャットを使って検証してみます。

※Amazon Qは日本語サポートされていないため、以降の検証は英語となります。英語が分からない方にも伝わるように日本語で補足します。分かりやすくするために一部和訳を簡略化しています。

AWSについての質問

まずは軽くお試しとして、AWSのサービスに関する質問をしてみます。

AWSサービスについての質問

「 データベースを持つウェブアプリケーションをデプロイするにはどうすればよいですか？」

回答

1. EC2を使います。手動でのローンチでもCloudFormationやEC2 Auto Scalingを用いた自動デプロイでもできます。
2. 高可用性の確保のため、ELBを使って負荷分散を実現します。
3. データベースは、リレーショナルデータベースならMySQLやAurora、NoSQLデータベースならDynamoDBが使えます。
4. 自動デプロイのためにElastic Beanstalkを用います。
5. サーバーレスアプリケーションであれば、API GatewayやS3, DynamoDBを用いつつLambdaを使って実現できます。
6. CodePipelineを用いてCDを実現できます。

こちらが曖昧な質問をしているので仕方ないですが、一般的な答えが返ってきました。Amazon Qは対話式なので、↑の回答について追加で質問してみます。 回答の1.の「CloudFormationやEC2 Auto Scalingを用いた自動デプロイ」について、両者の違いが分からなかったとして質問してみます。

追加質問

「CloudFormationとEC2 Auto Scalingの違いは何ですか？」

回答

1. CloudFormationはInfrastructure as Codeを実現するためのサービス。
2. EC2 Auto ScalingはEC2インスタンスを、必要に応じて自動でスケーリングするサービス。
3. CloudFormationを使うと、Auto Scalingグループを含め、インフラ全体をモデル化することができます。Auto Scalingはそれ自体ではAuto Scalingグループ内のEC2インスタンスの操作のみを提供します。
4. （省略）
5. （省略）

こちらも一般的な回答ですが、3.のように、「こういう違いがある」とピンポイントで説明してくれるのは良いですね。 AWSの公式ドキュメントを読めばわかる内容ではありますが、特に日本語の公式ドキュメントは何を言いたいのか分かりづらい初学者には理解しづらいことも多いので、対話式で分かることも大きいのではないでしょうか（とはいえ、これらの内容であればChatGPTなどの競合サービスでも十分な回答が得られそうですが）。

トラブルシューティング①：IAMロール

それでは本題に入りましょう。検証用に、Parameter Storeの値をLambdaから取得するという以下の構成を作成しました。

Lambda+Parameter Store

実際のコード等は以下になります。

Parameter Storeに格納された値を取得し、その値を返すLambda関数（左）Lambdaが取得する対象のパラメーター（右）

さて、この構成であれば、LambdaにはParameterStoreから値を取得するためのポリシーが付与されている必要があります。今回はあえて誤ったポリシーを付与しようと思います。

タイポしたポリシー

「parameter/ParameterKey」となるべき箇所が、「parameter/ParameterKez」となっているポリシーを付与したロールをLambdaに紐づけました。当然、Lambdaをテスト実行すると失敗します。

テスト実行失敗の画面。権限が無いというエラーが出る。

このエラーについて、Amazon Qに質問してみます。

エラーについて質問

「なぜLambdaファンクションがParameterKeyパラメーターを取得する権限を持っていないのか？」 「getParameterPolicyのポリシーで権限を付与しているのに、なぜLambdaファンクションがPrameterKeyパラメーターを取得する権限を持っていないのか？」と質問しています。AWS内のリソースも参照してくれるようなので、ARNだけ渡して質問しているのがポイント。

回答

GetParametersを許可するロールは付与されているようですが、ARNで指定した特定のパラメーターを取得するための権限がありません。以下のことを試してください。
1. 特定のARNのパラメーターの取得を許可するようにポリシーを更新してください。
2. 広めのポリシーではなく、パラメーターを取得するための最小のポリシーを設定してください。
3. Lambdaのロールに正しくポリシーがアタッチされているか確認してください。
4. 最新の許可が設定されているか確認するためにLambda関数を再実行してください。

所々怪しい回答（実際には付与していないGetParametersのポリシーがあると言っていたり、権限が無いというエラーにもかかわらず権限を絞るように言っていたり）もありますが、ARNが間違っているということはある程度読み取れる回答が返ってきました。もしかしたらピンポイントで「この部分のスペリングが間違っていないか」と指摘をもらえるのではと期待して色々な聞き方をしてみましたが、そこまでは上手くいきませんでした。

トラブルシューティング②：ネットワーク

続いて、ネットワーク系のトラブルについても実験してみました。以下のように、パブリックサブネットにEC2インスタンスを配置します。EC2インスタンスにはWordPressがインストールされている状態です。

EC2にはElastic IPを付与しているため、ネットワークが正しく設定されていればパブリックIPでアクセス可能です。今回はあえてセキュリティグループの設定を間違えてみます。

EC2インスタンスに、インバウンドルールが存在しないセキュリティグループをアタッチします。

インバウンドルールが存在しないセキュリティグループ

当然、パブリックIPでアクセスしようとしてもアクセスできません。

アクセス結果

そこで、このエラーについてAmazon Qに質問してみます。

エラーについて質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか？」

回答

ネットワーク接続の問題です。VPC Reachable AnalyzerとAmazon Qがネットワーク接続の問題のトラブルシューティングに役立ちます。プレビュー版を試用できます。（バージニア北部リージョンで利用可能）

VPC Reachable AnalyzerというVPCのリソース間の接続を確認できるサービスがAmazon Qとつながっているようです。回答のリンクから AWS Q for Reachability Analyzerを開きます。 Amazon Q同様にチャットで質問できます。

Reachable Analyzerでの質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか？」

回答

public IPを使ってEC2インスタンスに接続できないようです。接続またはセキュリティの設定の問題がある可能性があります。分析結果は以下。

分析結果の詳細を見てみます（ここは日本語）

インバウンドルールが適用できていないということが分かりました。 この分析結果は既存のVPC Reachable Analyzerと変わらないと思いますが、対話形式で分かるのでAWS初学者には使いやすいかもしれません。

まとめ

以上、Amazon Qの検証でした。個人の印象ですが、ある程度のトラブルシューティングはできるものの、核心を突いた回答までは得られないかなと感じました。 ある程度AWSを理解できている人にとってはサポートになると思いますが、少なくとも現状ではAWSがほとんど分からない人が使ってAWSを使いこなせるようになるものではないかもしれません。

Amazon Qはここで紹介した以外にも様々な機能があるので、また様々な活用方法を探してみたいと思います。 ここまで読んでいただいてありがとうございました。

さいごに

弥生株式会社では一緒に働くエンジニアを募集しています！詳細は↓よりご確認ください。

herp.careers