検証サイトに「物件情報がない…」ーAWS「Fargate・Lambda・SQS」を調査せよ！ー

初めまして。Ｃメディア開発部の黒田です。
新卒で入社して4年目となり、「不動産情報サイトアットホーム（以下サイト）」の「基盤」開発・運用保守を担当しています。

学生時代は、ITとは無縁のゴリゴリの体育会系でずっと野球をやっていました。
当時の私にとってPCは、プログラミングやコマンドを叩くためのものではなく、
映画を観たり大学のレポートを提出するためだけのものでした。
タイトルにある「AWS」なんて存在すら知りませんでした。

今回はそのような私がしばしば対応する「検証サイトに物件情報が表示されない」というトラブルを切り口に、サイトに物件情報が公開されるまでのAWSサービスと運用業務の紹介をしながら、「便利だと感じたこと」や「難しかったこと」を素直に書いてみます。
開発に出会った時からクラウドサービスがあった世代なので、
オンプレミスと比較して「いままで膨大な時間をかけてやっていた作業が…」
だったり「設定がすごく簡単になった！」という感動は想像することしかできません。
そんな私と同じ世代のエンジニアや、これからエンジニアを目指そうと考えている人に共感してもらえるような記事にしたいと考えています。
有識者の方には、「もっとこうした方がいいぞ」や「そんなのはもう古い、今はこうあるべき！」などアドバイスしていただければ幸いです。

それでは本編にまいります！

【トラブル発生】検証サイトに「物件情報がない…」
【経路確認】物件情報が消えた場所は「Fargate・Lambda・SQS」
【調査①】Fargate（バッチ）を調査
【調査②】Lambda（バッチ）を調査
【調査③】SQS（キュー）を調査
まとめ
おまけ

【トラブル発生】検証サイトに「物件情報がない…」

サイトは、リプレース・機能追加・障害対応…などなど毎日開発が行われています。
検証サイト（社内のみ公開）では、開発中のバグにより、
「（あるはずの）物件情報がない…」ということが週に何度かあります。
※本番サイト（全世界に公開）では、そんなことはほとんどありませんのでご安心ください。
検証サイトに「（あるはずの）物件情報がない…」状況では、
検証チームが検証を進められず困ってしまうので迅速に対応する必要があります。
今回は、そのような場合の原因調査とリカバリ対応についてお話ししたいと思います。

【経路確認】物件情報が消えた場所は「Fargate・Lambda・SQS」

突然ですが、例えば＜学校の食堂で「スマホがない…」ということに気付いた時＞をイメージしてください。
「学校の最寄り駅まではあった（支払いに使った）」
↓
「教室でもあった（調べものをした）」
↓
「体育館のロッカーに入れた、出したっけ？」
というように「スマホ」が辿った「経路」を思い浮かべて「消えた場所」を絞り込むかと思います（そういうことにしましょう）。
私も、検証サイトで「物件情報がない」という連絡を受けた時、
「物件情報」が辿った「経路」を思い浮かべて「問題箇所（消えた場所）」を絞り込みます。

サイトの「物件情報」が辿る「経路」は以下の図のようになっています。
※この「経路」は実際のシステムから一部を抜粋したものです。
赤で囲まれたAWSサービス（Fargate・Lambda・SQS）を順番に調査していきます。

【調査①】Fargate（バッチ）を調査

（1）問題箇所の特定：「Fargate（バッチ）」が異常終了したのか？

「Fargate（バッチ）」が異常終了した場合は「Teams」に下図のようなアラートを通知する仕組みになっています。
アラートなしの場合は「調査②」へ進み、アラートありの場合は「Fargate（バッチ）」のどこで問題があったかを調査します。

（2）問題箇所の特定：「Fargate（バッチ）」のどこで問題があったか？

「Fargate（バッチ）」は「EventBridge」で定期実行し「StepFunctions」によって複数処理を制御しています。
「StepFunctions」内の「進行中（のまま停止）」や「失敗」状態の処理が、問題があった処理と特定します。

（3）問題箇所の対応：「CloudWatch」でエラーログを調査・対応

各処理は「CloudWatch」にログ出力しているため、問題があった処理のログを「CloudWatch」で検索し異常終了の詳細を調査します。
配属当時はログを確認することも難しく（暗号のようでした）、「こんなエラーログがでてました」と報告するだけでしたが問題と対応方法を都度記録していたので、今ではおおかた自力で対応できるようになりました。
対応したことや新しく覚えたことを記録しておくことは大切ですね。
ちなみに、「Fargate（バッチ）」は「S3」にファイルを配置することで再実行させることが可能な仕組みになっており、便利さを実感しています。

【調査②】Lambda（バッチ）を調査

「Fargate（バッチ）」が異常終了していない場合、「Lambda（バッチ）」のトリガーが「Disabled（無効化）」になっていないかを確認します。
「Lambda（バッチ）」の検証リリース不備や、「SQS（キュー）」のデータ不正、夜間に動いている連携処理の失敗などの問題で「Disabled」状態となってしまうことがあります。
トリガーが「Disabled」になっていた場合、上記の問題へ対応した後、「Enabled（有効化）」に変更する対応を行います。
トリガーが「Enabled」になっていた場合、「調査③」に進みます。

【調査③】SQS（キュー）を調査

「Lambda（バッチ）」のトリガーが「Enabled」になっていた場合、
「SQS（キュー）」に「メッセージ（物件情報が登録されたという通知）」が受信できているかを調査します。

（1）問題箇所の特定：「SQS（キュー）」に「メッセージ」は通知されているか？

「SQS（キュー）」の「モニタリング」機能で「受信済みメッセージの数」を見ます。
下記のキャプチャでは何件か「メッセージを受信している」ことが分かります。

（2）問題箇所の対応：「SQS（キュー）」にメッセージ受信なし

「SQS（キュー）」にメッセージ受信なしの場合、メッセージの送受信の連携設定に問題がある可能性が高いです。
というのも、検証環境ではメッセージ送信元のシステムも受信先の「SQS」も複数あり
リリーススケジュールによってつなぎ先を変える仕組みとしているため、連携設定の不備や利用者の認識齟齬が発生することがあるのです。
例えば、設定1・2のように連携設定している場合があります。

設定1「送信元-2023年4月リリース」ー「受信先（SQS）-2023年3月リリース」
設定2「送信元-2023年5月リリース」ー「受信先（SQS）-2023年4月リリース」

この例では、「送信元-2023年4月リリース」の環境に物件情報を登録しても「受信先（SQS）-2023年4月リリース」に届かず、メッセージ0件…という状況になります。
設定を修正する、検証チームに物件情報の登録先を変更してもらうなどの対応を行います。

（3）問題箇所の対応：「SQS（キュー）」にメッセージ受信あり

先のキャプチャのように「SQS（キュー）」にメッセージ受信ありの場合、重症です。
メッセージの中身を確認して、問合せのあった物件情報レベルで受信状況を確認、
データベースに抜け漏れなく物件情報が登録されているか確認…
など、どの部分まで連携されたのか、より細かく調査し、対応を行います。

まとめ

サイトに物件情報が公開されるまでのシステムの流れをご紹介し、
運用業務として開発中トラブルの調査と対応についてご説明させていただきました。
初めは、ただ目の前のトラブルに対応していくだけでしたが、
今はもう少し余裕ができて「もっとこうしたら楽にトラブル対応ができるな」だったり
「このトラブルにはもっと早く気付けるようにしたいな」と考えるようになりました。
今は1年目のころに比べてシェルスクリプトやLambda関数を簡単に作れるようになっているので、もっと改善提案していきたいです。

私が入社１年目のころに当時のOJT担当者から
「何か分からないことがあったら何がどう分からないのか記録しておくといい」と常々言われていました。
分かる人は、分からない人の気持ちを理解しづらいので、
自分が教える立場になったときに、分からない人の気持ちを忘れてしまいがちです。
分からない人の気持ちを分かっていないと独りよがりな説明となってしまうので、大切なことだなと思います。
そんな思いもありながら、特に1年～2年目の時は、とにかくノートや社内Wikiツールに記録するようにしていました。
説明していただいてもよく分からないと思ったことも、自分が対応したことを理解できていなくてもひとまずそういうことなんだと頭に入れて記録していました。
それがどんどん蓄積されるとともに、自分のできることが増えていった手応えがあります。
その過程が、運用・保守業務の面白さでもあるなと感じています。

最近は新しいことを覚えて記録する機会が減ってきたので、
改めてアウトプットの大切さをこの記事を執筆するにあたって感じました。
また、私の業務のなかでご紹介できそうなことがあったらここで記事にしたいと思っています。

最後まで読んでいただきありがとうございました。

おまけ

私の所属するCシステム開発グループの基盤チームには中堅～ベテランの非常に優秀なエンジニアがたくさんいらっしゃいます。
せっかくの機会なの（と僕の単純な興味）で、数名にご協力いただき「好きなAWSサービス」とその理由を聞いてみました。

川村さん Kさん
アットホーム歴：10年
好きなAWSサービス：Cloudfront
理由：サービスの入り口でディレクトリ管理の用途にあわせた細分化とキャッシュにてサーバーの負荷軽減し、Webサーバでの複雑なリバースプロキシ制御を外に出し開発は業務のみに集中させることが出来るため。