１月から３月までの３ヶ月間、株式会社CyberZで内定者アルバイトを経験してきたので、振り返りを兼ねて体験記を書いていきます。
就業形態は１月が週３で出社、２月は週２でフルリモート、３月は平均すると週３になるくらいで出社という感じで３ヶ月間やってました。
ちなみにCyberZに内定者アルバイトとして参加するのは今回が２回目であり、１回目の後悔や反省点をめちゃめちゃ意識して動いていたので、かなり充実させることができたと思っています。
１回目の時の体験記もあるので、興味のある方は覗いてみてください。
ではさっそく本編に入りましょう！
以下余談です。
今だからこそ言えるのですが、１回目の際に開発していたマイクロサービスは現在OPENREC.tvでリリース済みの「ふくびき機能」でした。
↓ 参考 ↓
配属先
今回のアルバイトではCyberZの開発本部に配属され、新規サービスの開発に携わっていました。
ポジションとしては、１月から２月の半ばまではサーバーチームのメンバーとしてがっつりアプリケーション開発に参加しており、その後から３月末まではSREとしてアプリケーションから離れた領域の開発を行っていました。
受け入れ面談の際にも、アプリケーションとSRE業務の両方をやりたいと伝えており、実際にやりたいことは全部やらせてもらったため、とても充実した３ヶ月間でした。
新規サービスのバックエンド開発メンバーは、サーバーチームが２人でSREが１人という少人数で動いているということもあり、割と自由になんでもできるという環境がとても自分に合っていました。
また、CyberZにはSREのロールモデルとして最適だと思っている方が在籍しており、その人の近くで就業できる環境がめちゃめちゃ良かったですね。
取り組んだこと
ここでは期間中に実際に取り組んでいた内容について紹介します。
以下にサーバーとSREのそれぞれの取り組み内容を列挙します。
【サーバー】
- サービス内通知機能の実装
- 一部機能の設計（ここは詳細を割愛）
【SRE】
１つずつ詳細を見ていきます。
サービス内通知機能の実装
１月から２月頭にかけて、サービス内通知機能実装におけるサーバー側の舵取りを担当していました。
サービス内通知機能は↓みたいなヤツのことを指しています（画像はGitHub）。
要はサービス内で起きる何かしらのアクションを該当ユーザーに通知するための機能を実装したということです。
具体的に自分が行った内容はこちらです。
ただ実装するのではなく、１つの機能開発を仕様決めから丸っと一人で担当させていただいていました。
このタスクでは、自分が決めたことをサーバーチーム内で共有、必要に応じて議論するという工程が何回かあったので、本当に一人の社員としてチームにジョインできている実感があり超楽しかったです。
また、設計の際にはパフォーマンスや今後の拡張性なども思いつく限りは考慮するようにしていました。
新規サービスはサービスの特性上、通知のリアルタイム性があまり求められないだろうという考えがあり、データベースはライトヘビーな構成にし、SELECT時のコストを削減する方針で設計をしました。
具体的には、通知を管理するテーブルにはユーザーキーなどの外部キーを一切持たせず、必要な情報は全てリテラルで保持させることで、取得時にリレーションが不要になるようにしていました。
通知機能の実装は初めてだったので、諸々の設計が最適解だったのかどうかはまだわかりませんが、割と色々考慮した上で実装まで行ったので、本番運用する時にどうなるのかが気になります。
バッチ処理のアラート通知実装
１月の３日間くらいでSRE業務の導入タスクとして、バッチ処理のアラート通知をSlackに送信する機能の実装を行いました。
新規サービスでは、KubernetesのCronJobリソースを使ってバッチ処理を定期実行しており、Jobが失敗した際に、その情報をSlackの特定のチャンネルに送信するように既存のシステムを拡張したという内容になります。
このタスクでは、今までほとんど触ってこなかったツールの設定をいじることになったので、非常に新鮮な経験だった記憶があります。
ここは導入タスクということもあり特に言うこともないので次に行きます。
ArgoCDのアーキテクチャ、CDフローの改善
２、３月の約１ヶ月間でArgoCDのアーキテクチャとアプリケーションのCDフローの改善に取り組んでいました。
具体的に取り組んだ内容を以下に列挙します。
- マニフェスト管理ツールをKustomizeからHelmへ一部移行
- サーバーアプリケーションに関するマニフェストをリポジトリから切り出す
- ArgoCDの同期先の切り替え
- リポジトリを跨いで行っていたCDワークフローの統合
ここのタスクは背景の説明が必要になるので、ちょっとだけ背景について説明します。
以下背景の説明。
新規サービスのサーバーアプリケーションではMonorepoを採用しており、基本的にはサーバーに関するアプリケーションを１つのリポジトリで管理しています。
また、それとは別でKubernetesに関するマニフェストなどのファイルはKubernetes用のリポジトリとして別で存在しています。
この状態だと、バッチ処理を行うCronJobなどの設定を調整したいと言う場合、サーバーメンバーはSREが管理しているリポジトリを変更することになるので、SREチームを介して変更を行う必要がありました。
CronJobなどのアプリケーションと密接な設定はサーバーチームだけで気軽に調整できた方が良いと言う話があり、そこから「サーバーアプリケーションに関するマニフェストはサーバー用のリポジトリで管理するように変更しよう」と言うことが決まりました。
また、従来のCDフローでは、サーバーとKubernetesのそれぞれのリポジトリにあるGitHub Actionsで以下の処理を続けて実行することで、環境に変更をデプロイすると言う流れになっていました。
- imageのビルドとECRへの登録（サーバー）
- ArgoCDが監視しているマニフェストに記述されたimageタグ名を切り替える（Kubernetes）
この方法では、デプロイのたびにリポジトリを跨いで２つのワークフローを実行する必要があると言うことに加えて、kube側のワークフローを実行する際にimageのタグ名（サーバー側のリポジトリのコミットハッシュを使っている）を手動でコピペする必要があり、ちょっとした手間がかかるものとなっていました。
ここまでが背景の説明になります。
マニフェストの置き場所をサーバーリポジトリに変更したことで、imageのビルドを行うワークフローとArgoCDが監視しているマニフェストの置き場所が同じになったため、２つのワークフローの統合とコピペ工程の除去ができるようになりました。
このタスクは、最初に「こう言うことやりたいと思ってたんだよねー」と言う風に抽象的な要件でアサインしていただき、そこから自分なりに具体に落とし込んで着手していました。
タスクを進める中で、サーバーチーム内で「どういったフローでデプロイできた方が嬉しいか」といった要件の吸い出しなども行いつつ進めており、SREとしての業務の一端をかなり味わえたのではないかと思っています。
ちなみに改善後は下の画像のようなワークフローになっています。
APIのみ少し特殊で、Swaggerのデプロイを追従させるかどうかのオプションを搭載させています。
実際にヒアリングによって出てきた追加要件（上のSwaggerを追従させるやつとかが該当）なども加味しつつ新しいワークフローを整備するところまで完了したので、ほんとに達成感のあるタスクでした。
Argo Workflowの調査・検証と導入フローの整備
３月の最後の１、２週間ほどでArgo Workflowの調査・検証と導入フローの整備に取り組んでいました。
Argo Workflowは、Kubernetes上で動作するワークフローエンジンであり、今までCronJobで実行していたバッチ処理をこっちに置き換えようと言う話から調査・検証などを行なっていました。
と言うのも、バッチ処理で実行しているバイナリは引数を受け取ることができるのですが、CronJobだと動的なパラメータを与えて実行しようとすると、その工程が複雑になってしまい手間がかかると言う問題がありました。
これはバッチ処理中にエラーが起き、その分の処理を手動で復旧したいと言う限られた条件下での話ではありますが、そういったケースで簡単に実行できるようにしたい、と言う要望からパラメータ周りを柔軟に触れるArgo Workflowを導入しようという話になりました。
Argo Workflowを導入するために、期間中は以下の内容に取り組んでいました。
最終的に期間内ではやること全てを終わらせることができなかったですが、AWSの設定やKubernetes周りを色々触りながら実装ベースでインフラ周りの勉強ができたので良かったと思います。
振り返り
冒頭でも書いたように、今回は１回目の後悔や反省点をバチバチに意識していたこともあり、かなり自分的にも良い動きができたんじゃないかと思っています。
期間中に特に意識していたことの１つとしては、「この人ならこんな感じで立ち回りそうだな」といった自分の中にあるざっくりとした理想系を模倣するような形で業務に取り組むようにしていました。
結果としてコミュニケーション面や仕事の進め方など、割と良い感じに評価していただいたので良かったです。
一方で、もう少しチームをリードできるような存在になれるように努めないとなぁとも感じていました。
自分の考えなどを共有する際、やはりどこか自分の中でも自信が無い側面があり、結果として意思決定などのリードする力が欠けているように感じたので、こちらは今後の課題だと思っています。
ここは技術とこれまでの経験によって養われる力だと勝手に思っているので、テックリード的な立ち回りができるように今後も学習を続けていこうと思います。
おわりに
今振り返れば、１年前に初めて内定者アルバイトに参加した時は、バックエンドとしての実務経験がない状態かつインフラの知識がほぼゼロといった状態だったので、本当に１年間で多くのことを学ばせていただいたなぁと実感しています。
また、いくつかの会社をまわることができたということも、社員とのつながりを増やすと言う観点や配属先選びといった観点からも非常に有意義だったと感じています。
今まで学んできた技術や経験は確実にアドになると思うので、社会人１年目から大きなスタートダッシュを切れるように努めます。
内定をいただいてから今まで計４回（９ヶ月間）内定者アルバイトに取り組んできましたが、ついに明日から正式に社員として勤務することになるらしいです（他人事）。
正直ほんの数日前までオフィスに通って普通に業務をしていたので、全くといって良いほど実感が湧いていません…w
また、””今さらチュートリアルに戻るのかよ感”” が否めないと思ったり思ってなかったりするのですが、研修期間にしかできないようなこともたくさんあると思うので、これはこれで楽しもうと思います。
と言うことで、一年間お疲れ様でした（自分へ）。そして、明日から新しい環境を楽しもうと思います…!!
では、今回はこの辺で。
Bye 👋👋👋
