2021年サーバーサイドのエンジニアが使ってよかったもの10選

こんにちは!

Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。

カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。

例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けており2023年3月に走れるはずですので、それまでは気持ちを切らさずに適度に走り続けようと思っております。

f:id:ken39arg:20211206162114j:plain
先月の適度なランニング結果

40歳エンジニアの現実

さて、40歳で小学生の子供が2人いるとなると、なかなか業務外で勉強をして新しい知識を身につけるというのは難しいものです。

しかし、私が10年前に得意としていたガラケーやFlashなどのように跡形もなく消えてしまう技術があったり、陳腐化してしまい需要がなくなってしまう技術も大変多くあり、それらを正確に予測するのは難しいものです。そのため新しい知識の習得無しでエンジニアとしてコードを書き続けるのは難しいというのも、とてもつらいことですが現実であります。

それでもなんとかエンジニアとして第一線でコードを書き続けたい私にとって、業務内で新しい分野に切り込むこと、あるいは新しくなくとも普段使っていない技術を使うことなど、業務から日々知識を吸収し新陳代謝していくことがとても重要です。

今年の私は、幸運なことに、フェーズや規模などの全く異なる3つのプロダクト開発に関わることができました。 おかげで技術として新しいかどうかはさておき、私にとっての初体験をたくさんすることができました。

そんな今年「はじめて使った結果、いいね!」と感じたものを箇条書きで紹介いたします。

尚、恥ずかしながら詳しく解説できるほど使いこなしているとは言えないので、具体的な解説は適宜ドキュメント等をご参考ください。

クラウド製品

App Engine(GAE)

  • たまたま関わったプロジェクトが運用面の観点から採用していた
  • 使う前はGAEはECSかLambdaのどちらかに類似するサービスという印象を持っていたが実際は中間
  • AWSでいうと使ったことは無いけどElastic Beanstalkが近い
  • Goで利用したがプロダクトをビルドする必要もなくhttpサーバーが立ち上がるコードをGAEにデプロイすれば後はよしなにやってくれる

Datastore(Datastore モードのFiresotre)

  • AppEngineを採用していたプロダクトで利用
  • スケーラブルで柔軟なクエリを使えるNoSQL
  • NoSQLとはいえ使い勝手はRDBに近いためSQLを隠蔽したORM(のようなもの)を経由するとほぼ同じように使える。
  • とはいえ全く同じと勘違いすると大火傷をする
  • 少なくとも祖先(Ancestor)という概念と結果整合については正しく理解してから使わないと危ない
  • 手元で開発するときはDatastore エミュレータ が利用できる

Cloud Logging

  • フルマネージドなログ管理、AWSでいうと CloudWatch Logs
  • 構造化ログとの相性がよくGUIがメチャクチャ見やすい

Cloud Trace

  • 分散トレーシング、AWSでいうとX-Ray
  • GAEなどは勝手にトレースされている。
  • OpenCensusを利用して超簡単にトレースを仕込める。
  • X-Rayも順分使いやすいけど、自動的に収集される部分やCloudLoggingとの連携などこっちのほうが好きかも

DynamoDB

  • AWS上にとあるマイクロサービスを作る際に採用
  • スケーラブルで柔軟なクエリが使えるNoSQL
  • Datastoreと同じく結果整合(強整合も選択可)で使い勝手もかなり近い。
  • ただしDatastoreとは制約部分などは結構違いがあるので同じ感覚で使うと半分くらい作り直すことになる(なった)
  • 手元で開発するときはDynamoDB ローカル が利用できる

Sentry

  • エラー監視ツール
  • SDK経由でログを送ることで同一のエラーをまとめ1つのissueとしてsentryのダッシュボードで管理することができる
  • リリース後の監視も重要ですが、開発環境での動作確認でのエラーとその対応管理にとても便利
  • Cloud LoggingとCloud Traceを体験してしまうとCloudWatchLogsとX-Rayだと物足りなくなってしまった気持ちをより良い形で解決してくれた印象
  • aws logs tail から始まるシェル芸から卒業できそう

ghcr.io

  • Githubのリポジトリ毎に作成できるDockerコンテナレジストリ
  • Privateレジストリを使ったプロダクトに外部パートナーさんに開発に参加してもらう際や、マイクロサービスのDockerイメージのpush先としてりようすることでGithub以外のアカウントが不要になる
  • github actions からのpushでも認証情報が不要なのでとても助かる

開発ツール等

Docker Buildx

  • Docker imageをマルチアーキテクチャでビルドできるdocker コマンドのプラグイン
  • docker build ...docker buildx build --platform linux/amd64,linux/arm64 ... みたいにすればマルチアーキテクチャでビルドできる
  • マルチアーキテクチャビルドと便宜上いっているが、厳密にはアーキテクチャの異なる複数のイメージをマニフェストを用いて管理している
  • マルチアーキテクチャ以外にも便利なことができそうだけど必要になっていないので知らない

今年、PCのリプレイスでM1 MBPが支給されたのですが、M1のアーキテクチャがARM64であるためAMD64にしか対応していない一部のDockerイメージが動かなかったり動いても遅かったりするという問題が発生しました。 MySQL5.7などarm64対応が無いイメージの場合は代替案(8.0やMariaDBを使うなど)が必要になるので話は別ですが、自分が作っているイメージについては、arm64,amd64双方に対応したマルチアーキテクチャ対応でビルドすれば解決しますので積極的に使って行くといいと思います。(例: kayac/go-katsubushi対応したpull request)

crane

  • リモートのレジストリやイメージを操作するためのCLIツール
  • ghcr.io のprivateレジストリにイメージをおいている場合、開発では便利だが例えばECSなどのgithubアカウントがない場合に利用できない課題がある。そこでECSなどから見える別のリモートリポジトリにコピーしたい場合などに、簡単に利用できるコマンドがある。(crane cp <src.registry>:latest <dst.registry>:latest)
  • もちろんマルチアーキテクチャイメージにも対応している

Buf

  • Protocol buffersのバージョン管理ツールのようなもの(厳密に言うと違う)

もうIDLを使わずにAPIを実装するのはご遠慮させていただきたいなと思っている昨今ですが、そんな中でもProtocol Buffers が一番のお気に入りです。 これまでProtocol Buffersを使う際は、Prototool でlintしてprotoc でビルドするような運用をしていたのですが、各プラグインのバージョン管理など がやや面倒でした。 そういったことがBufを使うことでたぶんだいたい解決します。

grpc-gateway

  • protocol buffers のプラグインでgRPC↔RESTful HTTP APIの変換するリバースプロキシを生成できる
  • 私のユースケースではgRPCは不要でHTTP APIのみが必要なため、grpc-gatewayのプロキシサーバーは生成せず、ServeMuxを利用してhttp.Handlerとして利用している
  • リクエストbodyがapplication/x-www-form-urlencoded でレスポンスは application/json で返すような(結構よくある)ケースの場合はOptionを工夫する必要があるが、ドキュメントに書いてあるのでなんとかなります

終わりに

弊社では多くの自社サービスをAWSを利用して運用しておりますが、今年はたまたまGCPを採用しているプレジェクトに特性を理解できる程度の期間参加した後、 別プロジェクトでAWS ECS上にマイクロサービスを新規構築するという感じだったので、いつもと違うことを体験して良きものを持ち帰るみたいな感じの流れを組めたので、結果的にとてもおいしい一年となりました。 例年は、年に2個くらい必ずしも技術に限らずなにか新しい知識を入れられればいいのかなと思っております。

もちろん、勝手に入ってくるケースもありますが(異動など)、自分から取りに行かないと1年間で1つも新しい知識を入れられなかったということもあります。 それでも信頼を得たり、たくさん開発した結果、基礎体力が向上しているなど、何かしら得ていると思うので焦らずいきたい今日このごろです。