簡潔な自己紹介
Howtelevision のとてもこじんまりしたデータ分析チームの一員です。データ分析者として、データの送受信を制御するスクリプトの本番実装を担当する事もしばしばあり、以下に語って行きたいのが特に去年（2023年）の秋頃に自分が携わった、時に厄介な側面を見せてしまう様な、最終的に無事に成し遂げられた本番実装の体験（冒険）談です。
課題背景
新卒者を対象とする弊社の提供している「外資就活ドットコム」とのサービスにおける既存推奨機能の改善が去年の7〜8月から既に議論されておりました。サービスデータの活用方法を幾つかマーケの同僚と議論した上で、「サービス使用者によって行われた連続応募の対象企業の関係性」の巧い定量化を発案し、採用する事にしました。
本番実装の背景
推奨機能の改善に必要なデータが BigQuery の DWH で保管されており、以上の段落で述べた定量化を行うクエリの出力結果を〜単純な表現をすれば〜外資就活の backend 側と繋げて置く必要がありました。そのために、弊社で試みた別の推奨機能（機械学習の要素を組み込んだ物）の実装時から整っていた AWS の SageMaker 環境で、BQ データを Redis （データを辞書型で保管する、とても便利なデータ管理・保管の仕組み）に格納する役割の python スクリプトを実行する方針が決まりました。
Python スクリプトの作成
この段階は最も根本的な所の一つで、担当していた自分として最も楽しい所でもあったと思います（職務内容として、データ分析者の私がソフト開発者その者である訳ではないけれど、coding の軽い経験があり、結構好きな作業だと思います）。BQ でのクエリ実行・出力データの dataframe 型の読み込みを制御する pandas_gbq 及び Redis へのデータ格納を制御する redis との python libraries もちゃんと存在し、「BQ よりの出力データ → Redis へ挿入」とのデータ転送を為す python code を割と簡単に書けました。
AWS での手動検証
一度出来上がった python script を AWS の局所環境で手動で実行するのに向けて、必須 python libraries を pip freeze で requirements.txt ファイルにまず出力させて置き、そのファイル込みで main.py を実行して見ました...さてと、読者の皆さん、その実行がどこで躓いたと思いますかねぇ...
...お題の通りに、必須 libraries のお互いに満たされない依存関係の地獄への入り口が少し開いてしまいました...
依存関係のヒドラとの戦い
これ程こんがらがった依存関係の問題に初めて対面していた事もあって、如何に対処して行くべきかはそもそも知らなかった所でした。絶妙な偶然として、依存関係地獄の開いてしまった門から出上がった、数えきれない本数の首の依存関係ヒドラが現れた時は丁度我が Product 本部の部長さんとの定例の時間と被り、部長さんとお二人で怪物退治の冒険に勇気を持って出ました！！すると、本来 10 分前後で円滑に終わる定例が 30〜40分も掛かる事になり、問題を起こしていた必須 library versions を虱潰しで一つ一つ調整して来た...ヒドラの首を一本ずつ切ったら、必須 libraries のお互いの依存関係が全て問題なく満たされる configuration を見付けられ、悍ましきヒドラをやっと倒せました！
退治済みのヒドラの遺体の真っ下に埋まっていた、「依存関係の問題を起こさない requirements.txt」との貴重な地図を GitHub の remote にも大事に保管して置きました。
自動実行の検証
部長さんの力を借りた事によって倒されたヒドラの退治をもって、AWS の EventBridge で予約の設定して置いた自動実行は何も障壁なく無事に動くはず！！、と〜ピチピチに膨らんだ、鮮やかな色の風船の様に〜晴れやかに期待していた私ですが、自動実行関連のログを実際に確認して見たら、風船がいきなり凹み、色も突然ダサイ灰色になってしまった：Redis にデータが何も格納されていないまま、予約時に自動実行された python script が〜やはり...〜 version 適合性 error を起こしていた必須 library の install で止まっていた...本体の切り刻まれた後に、ヒドラから生き残った数本の邪悪な首達の仕業でした...
...なので、log 機能との鋭い剣をもって、残りの首を一本ずつ狙いながら切って行きました！（それぞれの必須 library への対処法としては、最新の version を取り入れたり、そもそもその library を必須案件一覧から削除したりするなど、物に依りました）。
依存関係問題よ、さらばだ！
log 記録を複数回こまめに監査し、一本ずつ顕になって来ていたヒドラの首を一本ずつ切った挙句の果てに、ヒドラの残りの脅威を全て除外できて、Redis へのデータ格納を無事に〜局所・staging 環境の両方でも〜確認する事が出来ました！
これで、恩人であるヒドラ退治屋の部長さんの肝心なご支援を頂いた上で、本番環境実装を行うための準備が全て整いました！歴としたソフト開発者にとっては些細な体験談に過ぎないかもしれないのですが、データ分析者の私の観点からしたら一つの冒険的な作業でした！
お読み頂きありがとうございました！
