Wantedly では k8s (kubernetes) をサービスのプラットフォームとして利用しているのですが、 k8s を利用し続けるには、定期的な version の update を行い、セキュリティの問題の修正や、プラットフォーム自体の進化などを取り入れていく必要があります。 ただ、 Wantedly では、長年の運用により複雑化した update の検証や実作業、それによる update 作業の工数の増大、それらの課題が中々消化できないなど、作業や改善サイクルに関する様々な問題がありました。 なので、まずは、 k8s update での課題を GitHub Project に蓄積し、チームで少しづつ解決出来るようにする体制を作りました。そして実際に可視化した課題として、 update 作業の省力化、検証用環境の構築の簡略化、ツールのインストールの簡略化などを行いました。 特に update 作業については長年の蓄積で作業のステップ数が非常に多く、改善の工数もそれなりに掛かるため、一度に全てを改善するのではなく、作業ステップの洗い出しとその背景の分析、ボトルネックの発見、それらの自動化などの改善をタスクとして切り出す、など、分析と細かいタスクの分解にかなり力を入れて行いました。 これらの工夫により、これまであまり進められなかった改善が進むようになり、プロジェクト終了後も、徐々に改善が進んで、作業の工数がかなり少なくなってきています。

Wantedly 開発チームのメンバーとともに、 Wantedly の Rails 6 への update を行った。 多数の deprecated な機能や設定のリストアップと update, ライブラリの update, 過去の経緯で独自にやっていた部分を Rails way に寄せるなど、 update のための作業、将来的に update しやすくするための改善を多数行った。 また、Wantedly では独自に複数の Database にアクセスする仕組みを入れていたが、Rails 6 で公式に導入された複数 DB の機能を利用する形で、仕組みのリプレイスを行った。 これにより、独自実装の複雑さを減らしたのと、Rails が提供するリードレプリカへの接続の柔軟な切り替えが行えるようになり、特定の DB 負荷が高い処理を、開発者フレンドリーな方法でコードレベル、ジョブレベルで切り替えが出来、サービスがより安定するようになった。

アプリケーション開発や、各種ミドルウェアのデバッグ等で、標準出力やエラー出力のログを見るというのは有力な選択肢ですが、 Wantedly ではそれらを検索する仕組みが整っておらず、動いているコンテナのログを見るのが開発者にとって難しいという問題がありました。また、Wantedly では大量のコンテナが稼働していて、ログの量も膨大で、コスト的にも選択肢は限られていました。 そこで、当時は新鋭の OSS であった Grafana Loki (https://grafana.com/oss/loki/) の社内への導入をサイドプロジェクト的に行いました。 使いやすい検索や絞り込みの UI を備えていることから、社内のエンジニアに色々な用途で使われるようになりました。 導入初期はバグ等もありましたが、システムも複雑でなく、メンテナンスも容易かつ安価なので、導入以降はリーズナブルな手のかからない奴として社内で活躍しています。