Webhookでリソース作成を自在にコントロールする」でした。マイクロサービスのリビルドを行った話をしようと思います。ほうがいいよね、といった本旨ではありません。書いたマイクロサービス弊社のマイクロサービスの一つにカテゴリ分類専用のサービスが存在します。カテゴリやキーワードを登録しておくとルールベースでカテゴリ分類を行うもので、自然言語やMLを使うほどでもない大雑把な分類を低コストで実現するためのサービスです。するとカテゴリ分類が実行されるというシンプルなものです。2015年4月に作り始めたのでもう4年以上稼働しているシステムになります。使って実装をはじめました。独立したサービスなので新しい言語を持ち込むには最適のタイミングだったと思います。パフォーマンス出せるのではないかという期待もありました。無事サービスとしてリリースでき、今日まで稼働してくれました。4年間動かす上でインフラ周りの大きな変遷がありました。デプロイするという形式で動かしてました。インスタンス自体の管理をしなくてはならないものの、サーバーのリソースを専有して動かせるので安定して動かす事ができていました。上で走るよう変更しました。乗っけるだけだったので移行はスムーズでした。基盤が整ってからは共有のサーバーの上で動くようになりました。メモリ使用量の問題です。頻発してしまいました。512MBや1024MB消費することもあったので実装上のメモリリークも疑わしかったのですが、そもそも最低専有量が大きくて共用サーバーでは扱いづらいサービスとなっていました。載せてその上にアプリケーションを載せる2階建ての構造になっているので、どうしてもオーバーヘッドが大きくなってしまうみたいです。ようなものが出てきて事情が変わりつつあります。扱う上で発生していた問題がいくつか。コンパイルが遅い開発のタイミングで一番の課題はこちらでした。インクリメンタルビルドがあるものの、多くの場合コンパイル待ち・テスト待ちで手が止まってしまっていました。フルにビルドが走ってしまうと10分くらい待たされることもありました。メインで書いていたのでなおさら待ち時間への戸惑いを感じました。オブジェクト指向でありながら関数型のパラダイムを取りこんでいる特徴を持ってます。熟練度によって書き方が変わってしまう問題がありました。らしい書き方、関数型を意識した書き方などいろいろな表現方法があります。プログラムを書く上で「こういう書き方あるよ」と教えてもらってスキルアップできるのはとても楽しいですが、システムを保守する上でネックになりがちでした。知見があって、コーディングの方針が統一できていればよかったのかもしれませんがそこまでの体制は作れませんでした。サーバー運用に対して知見が溜まってなかったというのもあります。システムは社内初だったため不安定になったり、問題発生時に適切な対処が取りづらかったです。メインに戻ってしまいました。個人的にもしっくりきていてとても扱いやすい言語だと思っているのですが、プロジェクトの規模が大きくなってくるにつれ「型」の重要性が増してきました。よる効率的な開発が出来たりします。通さない限り気づかなかったりしてイマイチです。よさそうなのでは、と思うようになってきました。ときに感じていた課題点を解消できそうな点もよさそうでした。あとコンパイルの速さとかコンパイルの速さなんかも大事ですね。利用しているプロジェクトがすでにある点でした。社内にすでに触れる人が複数名いるというのは非常に心強いです。でかけそうなシステムを探してました。マイクロサービスです。独立したサービスで改修しやすく、APIの仕様も固まっており規模もそんなに大きくないという理由から、カテゴリ分類サービスを書き直してみることにしました。採用してテストコードを充実させながら進めていきました。レスポンスのカテゴリが1件入っているみたいな形で振る舞いを記述することができます。呼ばれる形式で、プログラムの実装言語によらず共通して定義することができます。日本語のドキュメントのような形なので非エンジニアでも何をしたいのかが明確になるメリットがあります。いうものがあります)。利用してテストを書いていきました。対応するコードを準備します。「ステータス200が返ってくる」に対応するコードだと以下のようになります。部分はパラメータとして利用できるので汎用的なテストコードを実現することができます。フレームワークを利用すると嬉しいのが、振る舞いの記述を追加してもその分だけテストコードが増えるわけではないという点ですね。同じ関数が再利用できるので、開発が進むほどテストコードに割く時間が減ってくる特徴があります。いったメソッドレベルでのルーティングが必要となってくるため、フレームワークを利用して見通しをよくするようにしました。書いていて思うのはやはりコンパイルが速くて快適ということですね。いった手法と相性がいいです。言語は筋肉が要求されるというのが実感できました。例外処理もないので、愚直にエラーをチェックして返り値にセットするみたいなのを頻繁に書く必要があります。返すという仕様がとても自然に思えてくるようになってきました。例外で横道から抜けられてしまうよりはちゃんと関数の結果として返ってくるほうが考慮漏れずに記述できる感じがします。記述が長くなってしまうことについては「筋肉、筋肉...」と思うことで納得しています。サービスリプレース業務の合間の気分転換にちょっとづつ進めること約半年、ついにサービスが完成しました。まわりのテストどうするか悩んだりきれいな設計になるようリファクタしてたりしてたら結構かかってしまいました。バイナリを生成できてしまうと強いですね...。最終的なイメージサイズもかなり軽量です。走るので、イメージが軽いことは起動の高速化にも繋がります。デプロイいよいよ実戦投入です。別タスクとして作っておき簡単にロールバックできるようにして切り替えました。問題なく動いてる...と思いきや大きな問題が。カテゴリ分類サービスを利用してるシステムの一部で予期せぬ挙動が起こってしまいました。仕様が変化しているのが元凶でした。パラメータ名がスネークケースではなくキャメルケースという...。版の実装のほうが間違っていて実装しており、利用側も実装を正に進めていたため、切り替えのタイミングでトラブルが起きてしまってました。切り戻してシステムを改修したところ無事動くようになりました。置き換えてみてメモリ消費量がどうなったかというとのようにリリースを境に大きくメモリ消費量を減らすことが出来ました。クラスタに余裕ができたので台数減らしたり、その分他のサービスを載せることができそうです。使って簡易的なベンチマークもとってみました。性能が上がるのは嬉しい誤算でした。分類結果は一致しているので大きくロジックを変えたつもりはないですが、コード的に完全移植したわけではないのでこのベンチマークは参考程度に見てもらえると。強い人が書いたら十分逆転もありえそうです。おわりに1機能が独立して動くマイクロサービスみたいな構造だとこういった置き換えが気軽にできていいですね。理解がだいぶ進んだように思います。明日は@shinyorkeさんの「データをいい感じに活用するためのアジャイルな言語化とその取り組み」です。CDO(開発担当役員)の小笠原(@yamitzky)です。Corp.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。