ID:480さん

スポーツ系Webサービスの開発で、プロジェクトの様々なフェーズに合わせてフロントエンド・バックエンド・インフラ・アプリと集中的に見る領域を切り替えてフルスタックに対応しております。 現在は遊撃部隊と称してSREと同等の立ち位置でPJのインフラ/DXの改善作業を行っております。 Reactを使ったフロントエンドの開発がとても久しぶりで、react-hooksやTypeScriptによる型の存在など一昔前のフロントエンド開発からするととても快適になったなと痛感しております。 バックエンドに関してはRoRを使っており、GraphQLサーバの構築を行っておりました。GraphQL Rubyのレスポンス量過多なリクエストの調査でauthorとのやり取りやLocustを用いた負荷計測など単純な実装のみではなく、包括的にリーダーシップを取って行動しました。 また、インフラについてはGKEを使ったk8sの構築をしており、大まかなインフラ作業（ノードプールの調整やローリングアップデートなど）がコンソールUI上からポチポチするだけで完結するのは非常に扱いやすく、普段インフラ作業をしないメンバーに対しても触ってもらったりするなどインフラの垣根も低くなったなと思いながらインフラを触っています。 インフラ環境の管理についてはIaCでリポジトリ上にk8s manifestを管理しており、Helmを使った各環境の差分吸収やArgoCDや自社ツールを絡めた継続的なデプロイフローなどを整備しています。 最近はWorkload Identity連携によるサービスアカウントキーの不要化や、TLSポリシーの制限、非推奨となったKESからESOへの移行などセキュリティを意識した対応も行っております。 2022年からはインフラやトイルの問題をよりスピーディーに解決することを目指し、SREチームを私主導で立ち上げました。 現在ではSREを中心とした開発活動を行っております。

ECサイトアプリのバックエンド開発をしています。 gRPCやGCPでのあまり触っていない技術領域を扱い、知見を得ました。 また、既存の在庫処理で在庫テーブル内に数量カラムを持っていたために、多数のアクセスが集中した際に行ロックの関係上スループットが奮わないという問題があったため、Cloud Pub/Subを用いてキューイングさせることでユーザーへの結果のリターンのみを先に行い、裏で更新処理を逐次行うといったような改善作業をやってみたりしました。 ただ、根本的な解決になっていないのでESで再実装することも考えたのですが、その前にそもそもの在庫処理に負荷がかかっていた処理が削除されてしまったので遊ぶことが出来ず残念でした。 マーケティングの方の要望で、AutoML Tablesを使った機械学習でのユーザーのクラスタリングもやってみました。 サクッとデータセットを作ってトレーニングしてみたところ真陽率が85%を超えてAutoML Tablesの凄さを感じました。 それだけでは味気ないのでCloud ComposerやCloud Functions, Cloud Storage, BigQueryを使った推論パイプラインを作ってみたりしました。 トレーニング・推論パイプラインとしたかったのですが、AutoML Tablesのトレーニングが1回につき3000円ほどかかるため予算の関係上、推論パイプラインのみの実装となりました。 作ってみて思ったのはCloud ComposerのベースとなっているApache Airflowがv1.10.1と古く（現在の最新verは1.10.8）、その関係で苦しめられた部分はありました（例えばAutoML Tablesの操作など一部GCPサービスの対応Taskが存在していない等）。 この作業で機械学習の面白さに目覚めて、現在統計解析や機械学習モデルの学習をしています。

ECでの売上を上げるべく、マーケティング部門と協力しユーザーの属性と購入した商品から商品を５つのカテゴリに大別し、そこからユーザーのおすすめ商品をスコアリングして算出するまでを実装。 機械学習の前処理についてはCloud Composer, Airflowを使ったパイプラインを構築し、加工したデータはBiqQueryやストレージに格納する。（BigQueryにはマーケティングが閲覧したいデータを、ストレージは閲覧の必要のない＆データ量の大きいものと分別） また、モデリングについては最初独力で構築していたがどうしても精度が50%を超えず、時間の関係上AutoML Tablesによるモデリング作成に切り替えました。こちらを使った場合には、精度は80~90%を計測したのでそちらを現在も使っております。 機械学習の知識が０から実装を開始し始めたのですが、時間が足りずパイプラインにモデルの継続的な改善処理などを入れることが叶わなかったり、マーケティング部門の要求に必要十分なものを作ったためこれ以上機械学習に対して深堀り出来なかったのが少し残念でした。

自社サービスのマイクロサービス基盤構築を担当。 ラムダアーキテクチャを主として構築し、自分の好きなGo言語をフルに使って組んでいます。 今までやってきた技術体系とは全く異なる技術分野で、刺激を受けつつ新しい知識を学びながらやっております。

ISP企業様の料金請求システムのサー バ運用を担当しました。 初めての運用案件で、この時にLinuxについてチームの方にお教え頂きました。 またこの案件ではユーザーの請求情報に関する本番DBを吹き飛ばすという大失態を犯しました。 幸いなことにバックアップ態勢が十分なされており、大きな問題となりませんでしたが、この経験から「人為的障害は必ず起こるものなので、システムとして耐人為的障害を高めなければいけない」ということを学びました。

薬品分析で使われるガスクロマトグラフィーを使った分析機械のシステムを構築しました。 組込系の案件ということでかなり緊張して挑んだのですが、周りの方に助けていただきながらこなした案件。 C++の案件でもそうだったのですが、メモリという概念を深く意識し学ぶことが出来ました。 また、テストに実際のガスクロマトグラフィー分析機を使うことができたのも貴重な経験でした。

某有名企業様が「当社のエンジニアでは出来なかったのでお願いします」と依頼してきた案件。 様々なSNSと連携しひとまとめのフィードとして購読できるというものだったのですが、フィード購読の部分がTwitterのタイムラインのようになっておりました。 このタイムライン画面が素早く上にスワイプすると、描画がカクカクするという感じでしたのでそこを滑らかに動くようにしました。 物凄く富豪的に書かれたJSだったので、そこを最適化することで実現できました。

既存のソーシャルゲームにリワード広告を新たに機能追加するという案件でした。 ここで初めてクライアント様と対面し、どのようなものを作り上げていきたいか？というやり取りをすることができました。 ソーシャルゲームという特性上、特定の時間（ログインボーナス取得時間）に急激に負荷が上がり、初めて高負荷というものを体験しました。

副業として行っていたフリーランス業として受託開発した案件。 詳しくは書けないのですが、簡単に説明するとチャットサービスのようなものの開発でした。 チャットサービスということなのでRoRのActionCableが使えないかな？と思ったのですが、さすがに医療系システムでしたのでまだ投入すべきではないと判断し、単純なポーリングで済ませました。

OSS開発をする上で毎回決まった体裁でREADME.mdを作っていたが、そこをテンプレートから生成出来るCLIツールがあったら面白いのでは？と考え、Golangの勉強も兼ねて作成。 Golangの言語仕様のシンプルさを味わえたが、Composite型の操作についてはもう少し何とかならないのだろうか？と諸々疑問に思うところも発見できた。 OSSとして公開していたところ、株式会社エウレカのCTOからp-rをもらうなど面白い体験もできた。