シニアエンジニアになった

4月1日から職場での肩書が「シニアエンジニア」になった。この肩書は勝手に名乗っているわけではなくペパボの職位等級制度によるもので、全部で8段階ぐらいある等級の中、入社時には3等級の「エンジニア」のだったのものが、1つ上の4等級となった。等級は数が大きいほど強いという意味になるので、ちょうどキルラキルの極制服ようだなとかねがね思っている。

この職位等級制度の詳しいことについては、ペパボのHRブログに書いてあるのでそちらを確認してほしいのだが、今回はちょうどいい区切りなので、自身が普段どういう専門性を持って仕事をしているのかについてかんたんに説明しようと思う。

今の自分の所属チームについて

ペパボへの入社は2019年の夏頃で、入社当初の配属はEC事業部のプロダクトチームであった。このチームは主に「カラーミーショップ アプリストア」というサービスの運用とそれらに関係する諸々の領域を担当をしており、後に事業部のチームの配置転換の際には「アプリストアチーム」として名前を改められ、私も現在に至るまでこのチームに所属している。

またそれとは別に2年ほど前からアプリストアチームと兼任で、可用性向上プロジェクトのメンバーとしてもアサインされて活動中である。このチームはメインの商材であるカラーミーショップの可用性を向上させるために、インフラ周りを中心に改善を行っていくために組織された事業部を超えた横断的なプロジェクトである。その中でも自身がメインで関わっているのが、可用性向上のための既存システムを Kubernetes 上でスケーラブルに動かす仕組みづくりで、 Kubernetes 上で稼働させるために必要な既存システムの改修などを行っている。

Vue(Nuxt) のフロントエンド開発

アプリストアチームでは主にバックエンドに Rails 、フロントエンドに Vue(Nuxt) が使われている。特にデベロッパーサイトと呼んでいる、アプリストアへアプリを提供しているデベロッパー向けのダッシュボードがあるのだが、それの立ち上げに大きく関わった。

カラーミーショップ デベロッパー

ちなみに立ち上げは入社してすぐの頃であったのだが、前職ではフロントはほぼ触っていなかったものの、CSSフレームワークなどを使ってウェブサイトを作っていた経験や、業務とは関係なく Nuxt を使ったウェブサイトを試しに作ったりして知見を高めた。その結果。年末ごろにはゴリゴリ Nuxt を書けるようになり、デザイナーさんが上げてくるモックアップから、デザインフレームワーク(Vuetify)のコンポーネントなどを提案して、それらを使って画面の実装することができるようになっていた。また素人ではあるもののデザインに関する基本的な感覚があったので、よりモックアップに近いものを作れる能力があることに気づいた。

既存システムの Docker & Kubernetes 化のための改修など

可用性向上プロジェクトでは、主にカラーミーショップという商材を Kubernetes 上で稼働させるために、それらに関係することであればアプリケーションの改修や、ミドルウェア・インフラ面にも踏み込んで対応を行っている。例えばこれまで行ってきた内容は以下の通り。

アプリケーションをコンテナイメージ化するため作業

  • 開発用のコンテナというのはかねてから存在したものの、コンテナ単体でシステムが動くものではなかったので新たに Dockerfile を作成
  • それらを GitHub Actions でイメージビルドする CI/CD パイプラインの整備
    • 当時はまだ全社的に GitHub Actions が導入されはじめたばかりだった
    • それにあたって必要になった自作 GitHub Actions の作成もした

「GitHub Packagesの最新n件を残して他は消す」オリジナルのGitHub Actionsを作った話 - Pepabo Tech Portal

ログのフロー設計とそのためのアプリケーション改修

  • 当初 Pod の Sidecar から直接 BigQuery に転送していたが、諸々の検討した上でログを集約する Statefulset な Fluentd のサービスを新たに立ち上げた
  • Rails でそれまでファイルに吐き出していたログを直接 Fluent への転送ができるようにした
    • その際に依存する Gem を最小限にするために新たにシンプルな Gem を製作して導入

シンプルに Fluentd にログ転送ができる RubyGem "awesome_fluent_logger" をつくった - windyakinってなんて読む

Kubernetes の上での設計やアプリケーション動作のために必要な Manifests を作成

  • 基本的にゴリゴリ書いていく感じ
  • 現状でもアプリケーションロールこそ分離されているものの、以降に際して1つの Pod に詰め込む単位などを検討
  • Twelve-factors に沿ってアプリケーションで読み込んでいる設定値を環境変数に逃がして読み込めるようにしたりする

ファイルキャッシュを永続化するためにストレージサービスを利用したシステムを構築

  • Kubernetes のライフサイクルとファイルキャッシュの相性が悪いので小さなアプリケーションを新たに用意して資産を活かせる形とした

レガシーなアーキテクチャをKubernetes上でも活かすために - Pepabo Tech Portal

開発支援のためのツール開発

Kuberenetes の環境を作って終わり！じゃなくて、実際に開発者に使ってもらえるようにするために開発を支援するためのツールを作っている。

ブラウザ拡張機能

開発環境の切り替えに必要な作業を簡略化するために初めてブラウザ拡張機能を作った。作った時期が悪くて Chrome の Manifest V3 に対応する羽目になった件については後日書く。

Slack Bot

Chat Bot というよりかは、最近 Slack が推している Slash command を使ったインタラクティブな画面を実装。開発者が自分の環境を Slack から作ることができるようになる。

大量アクセスによるインシデント対応

大量にアクセスが来ると色々と困ることがある。 k8s に完全に移行するといくらか軽減されるかもしれないが、まだ移行できていないためシステム全体に影響が波及しやすい。もちろんそういったことが起きない起こさせないために日々改善はしているが、起きてしまったときの対応も必要である。

実際に起きた時に何が原因になっているのかの初動の調査や、必要なアクセス制限の判断などを積極的にハンドリングしていた。またそれらをドキュメントやダッシュボード化してなるべく自分以外の人でも対応できるようにしていた。

最近は未然に防げる仕組みが整ってきたので出動回数は減ってきている。

安定したサービス提供のための改善レポート【2022年1〜3月】 | お知らせ・最新情報 カラーミーショップ 無料で本格的なネットショップ作成サービス

登壇・執筆等

口下手と言うか、単純にしゃべるのが下手すぎるのでこういう登壇の機会はあまりないのだが、一応表立ってしゃべることもある。

執筆というほどではないが、会社のテックブログには手厚めの文書がいくつかある。自分はどちらかというと、文章を書く方が得意なので「なにをやったのか」「どうやったのか」を世に出していくにあたっての質を大事にしているし、世の中は常にそういうものを求められるようになっていると思う。なんでも手軽にできる時代だからこそ、信頼度の高い内容を出していかなければならないように感じている今日このごろ。

シニアエンジニアになってどうですか？

実際のところ仕事内容には大きな差が生まれていない。ペパボの場合、シニアへの昇格は追認行為なので、立候補する際にはシニア相当の働きをしていると認められないとシニアになれないことになっている。であるからして、シニアになったからといって何かが劇的に変わるかというとそうでもない。ただ求められるレベルはこれからも上がっていくと思われるので、日々精進していくのみですかね。