インフラ業務，はじめました

二ーリー（Nealle）にジョインしてSREチームに半年と二か月弱いたので，今までどのようなことを行ったのかを思い出しながら書くことにしました．

参加経緯

インターンの参加経緯の話からのんびり書きます．

Nealleでのメンター（ワタシは裏で勝手に上長と呼んでいる）であるてぃんおじ @_tinoji さんがTwitterでAWSに興味のある学生を募っていたところに端を発します．

https://twitter.com/_tinoji/status/1483359185031286793

この頃，私は「お金のかからない範囲でプログラミングを行ってきました．実際に，技育展などのピッチコンテストで個人開発で制作したCLIツールを発表するなどの成果を着実にあげ始めています．しかしながら，実際問題として業務として使われるのはAWSをはじめとするクラウドインフラなわけです．お金のかかるサービスには現状手を付けていないし，方策も何もない状態から個人で学ぶにはいくら何でも限界がある．」という危機感を感じていました．
　そんな私にとってとても魅力的な内容だったことをよく覚えています．TwitterのDMでやりとりしているうちに（といっても割とすぐだった）面接となりました．

面接では，本当にいろいろなことを話しました．データベースのタイムゾーンの扱いであるとか，面接している側も私も面接らしくない雑談のような面接をした記憶があります．また，メンターのてぃんおじさんが前職時代，前述した技育展でスポンサー側の審査員として見ていたという話を聞いて，その世間の狭さに驚いたことがとても印象深く残っています．

第一印象

私が最初に抱いた感想としては，チーム開発とはこういうものをさすのか，という感想がありました．タスクのチケット管理がしっかり行われており，朝会でそれぞれが持っているタスクの進捗や課題，悩みをしっかり連絡・相談しあう文化だったので，心理的安定性がとても高かったことが印象に残っています．

ところで，この段階では私の技術力としては実に貧弱なものでした．この段階ではろくにAWSやGitHub Actionsといったサービスに触れていなかったので，見るものすべてが新しいもので，これから行う仕事すべてが私にとってはじめての経験でした．それからセキュリティに関わることから（セキュリティの話題はデリケートなので割愛しますが，私がいた期間にもいくつかのセキュリティ周りの改善が行われていました），後述するようなトイルの削減のための自動化などを行っていきます．

SREチーム

SREチームは発足当初，インフラ回りの課題が多くAWSやDatadogを用いて主にインフラ周りの業務を行っていたチームです（今はSREらしい業務もかなり増えたようです）．チーム全体のタスクとしてはトイルの削減であったり，バックエンドを実行するインフラストラクチャの管理や移行などが主なタスクでした．

私が行ったタスクはいくつかあるのですが，その中のいくつかを紹介したいと思います．

Park DirectフロントエンドのCD構築

初めに行ったのはフロントエンドのCI/CDの構築でした．当初どのような状態だったのかというと，サービス開始時から伝わるシェルスクリプトを更新時に手動実行するような状態でした．それをCodeBuild, CodeDeployを含むCodePipelineでCDの構築を行いました．これによって任意のタイミングで容易にデプロイを行うことができるようになりました．

Park Directバックエンドのコンテナビルド

Park Direct内で動いているバックエンドをコンテナで稼働できるようにビルドしてECRにPushするまでのワークフローをGitHub Actionsで構築しました．さらにその前段階で，すでに動いている実行環境で使用しているライブラリのバージョンをあげていく作業をベテランの方と動作のテストを行いながら進めていきましたが，バージョンを固定することで安定的な環境を得ることの重要さをしみじみと感じました．

DB接続数急増インシデント

さて，次は私がインシデントを起こした回について話していきたいと思います．
　発端は，Pythonがメイン言語であるNealleとしては珍しく，Goを使ったマイクロサービスを作ることになったことでした．と言っても，別に難しいことはしておらず，事前にわかっているコマンドでDBを叩き，得られたデータを別のシステムに渡すだけの仕組みでした．

その際に，DB接続の終了処理を入れ忘れました．
　この結果どうなったでしょう？実はこの段階ではまだ問題として認知できませんでした．

というのも，元々実行頻度がさほど多くなかったので，じわじわと接続数が増加していたもののすぐに表面に現れなかったので気づくことができなかったのです．またこのときの私は，別の問題を抱えていました．というのも，設定ミスによって本来叩くべきDBのアドレスを叩いていないという問題があったため，その修正をしている最中でした．その際，修正後のDBは叩けたのですが，別のシステムにデータを渡そうとしたところでエラーが発生してしまう問題に私はぶつかり，頭を悩ませていました．結果から言うとネットワーク周りの問題だったのですが，その問題が解決するまでの間，エラーが起きるたびにリトライが走ることになりました．その結果，ステージング環境のDBにおいて，DBの接続数とDBへの負荷が急増してアクセスが困難となるインシデントを起こしてしまったのです．

インシデントが発生してからの修正自体は比較的すぐ（一度サービスを落として一行終了処理 defer Close() を追加するだけ）対応しました．
　その後，私は今回の事象でのポストモーテムを書き，チーム全体での振り返りを行いました．この事象では様々なミスが重なって最終的にステージング環境のデータベースへの接続数上昇という結果になっているのですが，そこまでの過程で私自身のコーディングミスもありますし，レビューのプロセスに不備があったりなど，それぞれに再発防止のために改善していくことの多い事象となりました．後述しますが，私にとっては心理的安全性がとても守られていたことがとても印象に残る事象でした．

---

まあまあありがちなのですが，SREといいながらインフラ業務が多い（前述したように今はSREらしい業務も増えたようです）部署でしたが，前述したようにしっかり相談を行うことができるので，心理的にも作業のはかどるとても心地の良い環境でした．SREチームリーダーでありチームの雰囲気を明るくしてくれるてぃんおじさんに改めて感謝です．

余談: 時系列的には「フロントエンドのCD構築」，「DB接続数急増インシデント」，「バックエンドのコンテナビルド」の順で私は経験しました．

おわりに

今回はこの辺で終わりにしようかと思います．一応，上長には「あとで見るから好きに書け」とは言われてはいたんですが，さすがに書ける話題と書けない話題があるのでそれを選定するのにかなり苦労しました．
　本文の方では一切書いていなかったのですが，私としてはAWSをほとんど触ったことのないような状態から，Nealleでの実務経験で最終的にAWS Developer Associateを特に勉強することもなく取得するところまで成長できました．改めてNealleの皆様に感謝申し上げます．今日もNealleは積極採用中ということなのでよろしければ（https://jobs.nealle.com/）．

おしまい