Retty新卒エンジニアの入社半年間の振り返り

この記事は3つ目の20卒エンジニアの振り返り記事になります。2つ目の記事はこちら。

こんにちは、2020年4月に広告コンテンツ部の開発チームにエンジニアとして入社した佐藤です。

この記事では、新型コロナウィルスの影響で、入社初日からフルリモートワークとなった新卒エンジニアのこれまでをまとめていきたいと思います。

環境の整備

フルリモートワークになった際、最も弊害になったのは自宅の作業環境が整っていないことでした。

関西から上京してきたばかりで、慣れない生活環境かつ部屋にはベッドとテレビ台しかなかったので、新たな業務をするのはとても辛かったです。

そこでRettyのガジェット手当¹という制度を使い、モニター、マウス、キーボードを揃えて部屋の作業環境を整えました。

おかげで、とても快適な環境で日々業務を行っています。 f:id:rettydev:20201105180516j:plain

学生時代との違い

学生時代に休学していた2年間に、さまざまな企業でインターンをしていました。そこでは、タスクを振られてこなすだけの1人での開発が多く、他のエンジニアとあまり関わることがありませんでした。

しかし、Rettyでは複数のエンジニアでのチーム開発になり、エンジニアだけでなく営業の方々との連携や社外クライアントとの連携など、チームワークの中での開発でした。技術面では、はじめて教わることが多く、スクラム開発、AWS、Dockerなど知らない単語ばかりで、最初はかなり戸惑いました。

そんな私を気遣ってチームの先輩が声をかけてくれたり、まずは何をしたら良いのかを教えてくれました。おかげさまで、少しずつ自分のできないことが何か、今やるべきことが何かが分かるようになり、戸惑うことがなくなりました。

広告コンテンツ部門での開発業務

広告コンテンツ部門の開発チームでは複数のプロダクトを扱っており、入社してからは主にデータビジネスソリューションに関する開発をしてきました。

さまざまなプロダクトと幅広い技術を扱うチームなので、次々と新しい案件に触れることができ、やったことがない領域にも挑戦する機会が多くありました。また、それを開発チーム全体でサポートするような体制になっており、お互いに助け合って進めることができたので、とても働きやすい環境でした。

たとえば、データビジネスソリューションの1つ、ビッグデータ連携基盤「Food Data Platform(FDP)」のETL基盤のリアーキテクチャをやりたいと発言したら、今までほとんど触ったことのないAWSを用いた設計の責任者を任せてもらうことができました。

ビッグデータ連携基盤「Food Data Platform(FDP)」とは

Food Data Platform(FDP)は、広告コンテンツ部で管理しているプロダクトの一つです。

「企業が独自に保有するビックデータ」と「Food Data Platform」を連携させる事で、企業が運営するサービスにおいて新たな価値の創出や、マーケティング活用や、トレンド分析や商品企画・商品開発など、様々な企業の用途に応じたデータ活用が可能となり、結果としてサービスの質向上の助けになることができるプロダクトになります。

詳しく説明すると長くなってしまうので、気になる方はこちらを読んでみてください。

prtimes.jp campaign.retty.me

f:id:rettydev:20201009190513p:plain

このFDPは大きく分けて2つの要素で構成されています。

1つ目は、実際にデータを提供するためのAPIサーバー。 APIサーバーについては、20卒エンジニアの振り返り記事の1つ目で詳しく書かれているので気になる方は、こちらを読んでみてください。

2つ目は、雑種多様なデータをDWHにまとめるためのETL基盤。ここからはETL基盤のリアーキテクチャについて行ったことをお話します。

ETL基盤のリアーキテクチャ

背景

現在のシステム構成に移行する前のシステム構成図は以下の通りです。

f:id:rettydev:20201121140737p:plain こちらを見ての通り、様々なデータソースから抽出したデータをローカルPC上で加工を行い、最終的にS3やRDSにロードするようになっていました。

ここで課題として挙がったのは大きく3つです。

ETLの実行環境が実行する人によって異なること
ETLの実行に時間がかかること
ETLの実行中に問題が合った場合のリカバリーが難しいこと

主にローカルPCでの実行が要因であっため、実行環境をクラウド環境に移行することで解決することにしました。

設計

上記の背景で挙がった課題を解決するための技術選定の前提条件として挙げられたのは以下の通りです。

c5系のインスタンスが使える(もしくはそれと同等以上)
何らかのトリガーで簡単に実行できる
長時間実行に耐える(12時間以上)
docker imageが使用できる
ECS関連のサービスである(もしくはチームメンバーが利用経験がある)
docker containerに対して任意コマンドを実行できる
料金が安い(バッチ実行時のみインスタンスが起動するなど)

これら前提条件から選択肢に挙がったのは以下の4つです。

Cron on EC2

good:

様々な参考文献があり運用するにあたって安定感がある

bad:

goodの裏返しですが技術的に廃れている
EC2インスタンスの運用が発生する手間
ジョブスケジューラ系のツールを導入する必要がある

AWS Batch

good:

バックエンドがECSなので、ECSの資産を流用出来る
リソース管理は全く必要ない(vCpuとメモリをジョブ定義に指定するだけ、クラスタ管理不要)
SQSとECSをラッピングしたようなサービス

bad:

スケジュール起動は出来ない
cron用途ではない
docker pull時のキャッシュが効かない

ECSのサービス起動しているコンテナ内にcronを定義して実行

good:

ECSの資産をそのまま流用出来る

bad:

バッチ実行中にデプロイが走るとバッチが強制終了される
バッチの実行状況を一望出来ない

ECSのScheduledTask

good:

cron記法でスケジュールを定義する事が出来る
デプロイ時に実行中のバッチに影響を与えることがない
ホストを固定出来るためdocker pull時にキャッシュが効き起動が早い
cloud watch logsで起動処理の状況を確認できる

bad:

ジョブスケジューラにあるようなジョブチェーンの実行やリトライは出来ない

以上のようにいくつかの候補が挙がりましたが、前提条件をクリアしていることと、面白そうだなと思ったので最終的にAWS Batchを用いる事になりました。

そしてこちらが、移行後のシステム構成図となります。 f:id:rettydev:20201121141149p:plain

実装

AWS Batchに移行するにあたって、EC2の起動テンプレートを設定したり、並列処理を行なうために各ジョブ間のデータ共有のためEFSを用いたりと環境構築を行いながらAWSの知見を深めることができました。

特にAWS Batch上で実行されるジョブが安定しなかったり、ログが一定期間で消えたりと運用しながらでないとわからない要素がいくつかあり大変でした。運用にあたって大変だった点、どうすればいいのかという知見をドキュメントに残すことで誰でもキャッチアップできるようになったのは良かったと個人的に思います。

このように実際に稼働して運用できる状態に持っていく過程はとても楽しく、やりがいがありました！

しかし、これで終わりではなく最近ではAWS Bacthで実行する膨大なジョブを手作業ではなくスクリプトを用いてワントリガーで起動するようにしたり、日々運用を重ねながらブラッシュアップを続けています！