mopp

https://gyazo.com/63a2ff6f43268640387205843fcd7623

Quipper

Backnd enginner として入社

Ruby や Vim 界隈で活躍している ujihisa さんにリファラル枠で紹介してもらった

技術的負債を解消するためのチームに配属

既存のシステムは Ruby on Rails を主とし巨大な MongoDB を共有する分散モノリスだった

入社時点の話

2021年1月現在では新規サービスはマイクロサービスで開発しリリースという流れが確立されている

この巨大なモノリスを切り崩し、ビジネスをより高速に回す環境を整えるのがミッション

エンジニアの更に裏方みたいな感じ

ユーザに直接的に価値を与えるのではなく、他のエンジニアを経由して価値を与える業務

関わってきたサービスやプロジェクト

Ruby + Google Cloud Pub/Sub によるストリームデータ処理サービスの開発運用

イベント処理をモノリスから非同期アプリケーションとして Google Cloud Pub/Sub を使って切り出した

処理の可用性と信頼性の向上

ただし完全なマイクロサービス化ではない

実態としては Shared DB

Ruby on Rails 6による小さいマイクロサービス作成

3エンドポイントしかなく、view も提供せず、ドメインロジックもほぼ無い

一種のロギング用サービスで、投げられたデータを延々と貯め続けてたまに export するようなサービス

Ruby on Rails の入門には非常に丁度いいタスクだった

unicorn について少し詳しくなった

prefork はとりあえず true の方がいい

promtheus_exporter にも少し詳しくなった

トラブルシュートを何回かやったため

Thread 間で変数を共有した結果によるデータ競合が起きクラッシュするも Thread 内で例外を握りつぶしてループしていることにより、延々と無が実行され続ける

起動時にたまに無限ループして CPU 使用率 100%で張り付く

Elixir + Google Cloud Pub/Sub によるストリームデータ処理サービスの開発

またレガシーコードと向き合い、バグの発見、修正、曖昧な仕様を関係者に相談するなどしていた

軽量プロセスを用いたデータの書き込みのシリアライゼーションができてイケてると思った

New Relic のメモリリークをｼｭｯっと見つけて PR をマージしてもらえたのはうれしかった

ついでに便利なマクロも入れてもらったりした

動画配信プラットフォーム

ピタゴラスイッチ

AWS Lambda を使えるようになった

Web console 上でちょろっと書いて動くのはすごい

学んだこと

Kubernetes

未経験で入社した

現状は、一人で構築は出来ないがデプロイまで自動化されていれば問題なく使えるレベル

get して edit すればなんとかなる気がすると思ってる

kubectl apply もちょいちょいできるようになってきた

edit configmaps したあとに Pod の再起動をよく忘れるのはよくあること

負荷試験をやるために edit deployment してリソースを弄り回したりしたのでだいぶ慣れた

HPA は最高に便利

VPA もあるらしいが余り慣れていない

全てはリソース、という考えた方は UNIX 哲学ぽさがあっていいなと思った

Kubernetes 自体が非同期な分散システムであることは注意しないといけない

サービスを実装するにあたって Gracefull shutdown, liveness/readiness は特に注意が必要ということは学んだ

Pod 内に sidecar container を生やしたときの起動と終了の待ち合わせにはハマった

postStart とか graceful shutdown の設定を駆使しないといけない、公式でサポートしてほしい

Docker

すでに用意されていた docker-compose をよくつかうようになった

multi stage build は便利だと思う

DB

未経験で入社した

AWS Aurora (PostgreSQL) を一番使った

と言っても知ってるだけで活用はしてない

そもミドルウェアに強く依存するべきじゃないので、本当に必要にならない限りは DB の設定ってそんなにしないんじゃないだろうかと思っている

index を張るとかはよくやったが、正規化とかはそんなにやってない

MongoDB にもよく触れはしたが既にあるものを参照するばかりで構築などには関わっていない

Optimistic lock を自前で導入したりした

ActiveRecord, MongoMapper, ecto を使った

GCP

未経験で入社した

Cloud Pub/Sub, Cloud Run, BigQuery, Cloud Logging がよく触っていた

Cloud Build, Cloud Registory も一応触った

Cloud Pub/Sub はそれなりに運用した

Cloud Pub/Sub のせいで困ったり手こずったりしたことはなかったと思うので良いサービスだと思う

Cloud Run も scale out とかもいい感じにやってくれてすごいと思う

AWS

未経験で入社した

Aurora (PostgreSQL), AWS Lambda, Amazon S3, Amazon EventBridge

AWS IAM にはいつも手こずる

terraform

未経験で入社した

クラウドのプロビジョニングツールは初体験だったが思ったよりも簡単だし最高に便利だった

あと手動 apply はよくないので CI 化したほうがいい

Elixir

Erlang は前職で書いていたが Elixir は初めてだった

本腰を入れて書き始めると意外と多機能という印象

Kubernetes 上に Erlangクラスタを構築して軽量プロセスを分散させる感じのアプリケーション開発をした

軽量プロセスを利用したストリームデータのシリアライズは非常に良いと思った (自分が考案したわけではないが)

umbrella project でサービスを管理していた

個人ではなかなか書く機会の無い release 周りも大体書いたのでよい勉強になった

Ruby on Rails

未経験で入社した

上記に書いた小さなサービスで rails new から構築した

インフラの用意なども含めてチームで15営業日くらいで完了した

雰囲気がわかったかなという程度

view は全く触っていないので未だわからない

Go

未経験で入社した

Cloud Run 上で動く極小の Go アプリケーションを書いた

が、もう余り覚えていない

システムアーキテクチャ

技術選定をやった、とはまだ言えないがみっちり教えてもらって雰囲気を感じてきているレベルだと信じたい

メッセージバスを使ったシステムレベルの依存性の逆転はほんとすごい

アプリケーションアーキテクチャ

趣味で Elixir でちょっとやろうとしてみたが、型が弱い言語、小さいもの、でやるとうまみよりも面倒臭さが際立つ

大体の場合はこっちの形をベースにして、テストだけしやすいように DI をしておくのがよいのか？などと悩んでいる

コーディング

書き味よりも読み味

結局はバランス、というのはわかった上で言うが優先されるべきは読み味

書くのは1回だが読むのはN回

通常のアプリケーションコードでメタプロなど基本的には推奨されない

セマンティクスは大事

モデリングの大切さ

言うは易しだが実践はめっちゃむずい

エラー処理で毎回悩む

正常系を書くときの5倍くらい悩んでしまう

Backend enginner

バックエンドエンジニアに大切なのは作ったものの堅牢性

アプリケーションが

書いたとおりにスケールする

スケールのコントロールができる

変なデータが入ってきても弾く

コードが堅牢でおかしなコードが入りづらい

スクラム

未経験で入社した

本は1冊読んでたくらい

入社以降は3-4人チームでずっと回している

スプリントは1週間

チームのプロセスで一度失敗し、なんとか改善してスクラムが回るようになった

社内のスクラムマスターが開催する共有会でいろいろなことを教えてもらった

スクラムの根幹は経験主義にあり、検査、適応、透明性の3本柱が大切

スクラムガイド2020をスクラムマスターのアシストのもと2回読書会をやった

E2E の視点

E2E の視点とは「始点から終点の対応付けが同じレイヤーで出来ていること」

型が同じでなければ比較可能ではない、というような雰囲気

開発者が E2E の視点を持てているとは「顧客の要求と対応する成果物が何か理解していること」

この対応がわかってないで雰囲気で進めがちなので注意しないといけない

モニタリング

まずは可視化から

Datadog でグラフをいじるのが楽しくて社内でも関心が強い方になっていた

サブで New Relic を使っていた

パフォーマンスチューニングなどで DB へのクエリを見るなら New Relic の方が見やすい

機能の追加、修正、変更などの折にはログだけではなくてカスタムメトリクスを入れるのが便利

アラートで Slack に通知を入れたりするのがなおよい

ただし、スタックトレースや多くのパラメータがあるときは Sentry にも飛ばしたほうがいい

言語ランタイムのモニタリングのために prometheus exporter を利用して Datadog へメトリクスを流したのでそちらも少し分かる

SLI/SLO の設定なども SRE の啓蒙活動に応じてチームで行うようになった

その他

雑多に学ぶコンピュータ・アーキテクチャ勉強会をやった

言語

書ける

C, アセンブラ, Erlang, Elixir, Ruby, Vim script, bash

ちょっと書ける

Go,Rust,Java, Octave/matlab

触ったことはある

C++, Phyton, Node.js, Haskell, Lua, Pony, Scala

働く上で考えていること

楽しい開発がしたい

知らない技術を学びたい

楽しい開発が何か？はうまく言語化出来ていない

新しいことを学べる、尊敬/信頼できる人と一緒に働けると自分は満足できるのではないか？と考えている

こういうことやった/やっているとはっきり言える仕事がしたい

作ったものが外部にリリース/公表できるとなおいい

ユーザーファーストという言葉があるが、自分個人の興味としてはビジネスよりも技術である

ということをわかっているので、必要に応じてユーザのことも忘れないように振る舞うようにしている

チームとして業務をする

チームに属するメンバはバス因子を作り出さないように個々が務めるべきだと思っている

言い換えると、チームの人間が突然消えたときに影響が出るのは開発速度だけになるのが理想だと考えている

これと同じように他の個人ではなく他のチームと協力して業務をするようにしている

これも大体同じ理由

個人に責務を求めるのではなくチームに責務を求める

日々の開発のなかで思いついたメモ