問題の原因はエラーでなくワーニングだったお話

# はじめに
エラー解決に三日かかってしまったお話です。ストーリー形式になっています。
原因は記事の最後に記載しています。


# いつもと違う箇所を疑おう

```
Unable to fetch information about "domain name"
The security token included in the request is invalid.
```

私のチームは環境構築を進めていました。
普段通り納期の前日に構築を終える予定でしたが、serverless create_domainを実行するとエラーが出ました。

メンバーA「見たことないですね」

私「トークンが不正…？credentialsの中身間違っていたりしますか？」

メンバーA「間違っていなさそうですね」

私「configやcredentialsを一度作り直してからprofileを再指定してみますか」

<font color="Red">security tokenというエラーメッセージからまずはAWS credentials周りの確認を進めることにしました</font>


メンバーB「う～ん、ダメそうですね」


私「AssumeRoleでroleを切り替えた際に発行されるcredentialsでコマンドを実行できているか確認してみますか」


<font color="Red">ユーザー権限をAssumeRoleで切り替えていたので、切り替えが上手くいかずにReadOnlyのcredentialsになっているのではないかと思いましたがこの点は問題なさそうでした</font>

メンバーB「私のマシンでも試してみますね」

<font color="Red">環境周りの問題でもありませんでした</font>

私「構築手順を間違えているとかもないですよね」

メンバーA「手順書通りにやっているので問題ないと思います」

メンバーB「ですよね～。もう定時なので続きは明日やりますか」

<font color="Blue">翌日</font>

私「AWS周りが原因なのか確認したいのでSREを召喚しますか」

メンバーB「ですね、環境系は全く分からないです」

SRE-A「zoomに入りますね」


<font color="Red">問題の切り分けが出来ていないので、まずはAWS周りから攻めることにしました。Unable to fetch "domain name"と出ているのでAPI Gatewayに対して権限がないのではないかと考えていました</font>

SRE-A「CloudTrailでログを確認したところAssumeRole自体は出来ていますね。権限の問題はなさそうです。CLIからAPI Gatewayにリソース作成できますか？」

```
aws apigateway create-domain-name --domain-name 'domain name' --regional-certificate-arn 'arn' --region ap-northeast-1 --endpoint-configuration types=REGIONAL -aws-profile hoge
```

メンバーA「できましたね」

SRE-A「う～ん」

<font color="Red">今思えばこの時点で気づくこともできたな、と思います。リソース作成に必要に値を指定してCLIから実行したらドメインを作成することができました</font>

私「ドメインが出来たので一度環境構築手順に従って次のコマンドを実行してみますか」

メンバーA「次はserverless deployですね」

メンバーB「これで上手くいってくれれば…！」

```
Unable to fetch information about "domain name"
The security token included in the request is invalid.
```

メンバーA「また同じエラーです」

全員「な、なんだって～」

SRE-A「サーバレス側の問題ですかね」

私「使用しているバージョンに更新は入っていないですね、issueもなさそうです」

SRE-A「AWSサポートに問い合わせしてみますか、サーバレスも絡んでいるので回答がくるかはわかりませんが」

メンバーA「送ります！」

<font color="Red">このまま粘っても解決しそうにないので明日に備えるためこの日は解散しました。</font>

<font color="Blue">翌日</font>

私「回答きましたね、やはり認証情報周りが怪しいんですかね…」

SRE-A「SRE-Bさんお呼びしました！」

SRE-B「AssumeRoleで権限の切り替えは出来ていますね、サーバレスコマンド実行時の認証情報を確認できますか？」

メンバーA「問題なさそうです」

SRE-A「SRE-Cさんを召喚！」

SRE-C「EC2からサーバレスコマンドを実行できるか試してみるのはどうですかね」

SRE-B「ECRにDockerイメージをpush→EC2にログイン→ECRからイメージをpull→イメージ起動→コンテナ内でサーバレスコマンド実行という感じですね」

私「やってみますか」

<font color="Red">結果この方法は途中でやめたのですが、納品期日が迫っている状況下、原因箇所の特定ができない焦りから他の方法をとにかく試そうとしていました。そして全員の連携プレーでEC2でコンテナに入りサーバレスコマンドの実行を試すところまで辿りつきました。</font>

```
Unable to fetch information about "domain name"
The security token included in the request is invalid.
```

私「また同じエラーですね」


<font color="Red">万事休すかと思った矢先、SRE-Cさんが口を開きました</font>


SRE-C「因みにこのワーニングなんですか？」

```
Warinig: Invalid configuration encounterd at 'hoge': must match pattern "huga"
```


私「serverlss.ymlで対象箇所を確認してみましょうか」

メンバーA「S3のバケット名をパラメータストアから参照している箇所みたいです」

私「バケット名は正しそうですね、改行とかスペースは入ってないですよね」

メンバーA「あっ、改行入ってます」

私「…？他のパラメータも確認したいです。ひょっとしてドメイン名にも改行入っていたりしませんか」

全員「あっ」

<font color="Red">結果、この改行が原因でした</font>


メンバーB「いつも通りスクリプトでパラメータストアに登録していましたよね…後で原因は確認しておいた方が良さそうです。いつもはWarinig出てなかったと思うんですが、無視していたのが良くなかったですね」



# おわりに
各方面の協力により期日に間に合うことができました。原因は改行というまさかの結果でした。
ワーニングの内容は単純で、すぐ確認していればここまで大げさになることもなかったと思います。
一方、長時間SREと作業することがなかったので今回の一件で多くのことを学びました。
各自で調べて教え合ったりしながらエラー解決に向けて取り組む事ができたのは良い経験でした。