こんにちは、Sansan事業部でエンジニアをしている北見です。
5/29日、30日に渡り、Microsoft主催のカンファレンス「de:code2019」が開催され、幸いなことに参加することができました。 www.microsoft.com
本記事は、「de:code2019」に参加したメンバーによる3本のレポートのひとつです。 残りの2本に関しては近日中に公開予定です。
私からは、個人的に興味をもっていたトピックであるレガシーシステムに関するセッション
オイシックス・ラ・大地株式会社 「ここでしか聞けない !! マイクロサービス on AKS 導入のなま苦労話」
について、私見やエモを交えつつレポートしていこうと思います。
講演者である オイシックス・ラ・大地株式会社の長尾優毅氏とマイクロソフト・コーポレーションの寺田佳央氏による半対談形式のセッションで、 「エンジニアあるある」で示唆に富んだ内容の面白いセッションでした。
マイクロサービス化+k8s導入のきっかけ
食材のお届けサービス「オイシックス」
長尾氏によると、SpringBootで作り続けられていた相当なモノリシックシステム(開発19年)だったとのこと。
品質管理ができなくなり、スケールもしづらくなってきてしまったことで、システム刷新の必要性に迫られていたようです。
サービスを成長させるうちにツギハギが多くなっていき、手に負えなくなる...まさに「エンジニアあるある」じゃないでしょうか？
マイクロサービス化したことによるメリット
講演では以下のメリットが紹介されていました。
- 「サービス毎の開発/テストが容易」「エンジニアのモチベーション」
モノリシックなシステムだと、ひとつ弄ったらどこが壊れるか分からない...という恐怖心を抱えたまま開発しがちなので、(モノリシックと比較すると)安心して機能修正出来るのはエンジニアの精神衛生に良いですね。
- 「中途エンジニアの素早いプロジェクトへの貢献」
マイクロサービス化することで、途中でプロジェクトに参加しても素早く順応することができるとのこと。まさにその通りだと感じました。 弊社は中途入社が多いのですが、そういったメンバーが仕様の把握などを素早くキャッチアップすることは課題となっており、少し耳が痛い部分でした。
経験した苦労
一方で、メリットばかりではなく、導入にあたっての苦労もされたそうです。
- 「既存モノリスとの並行管理」
現行システムのメンテやアップデート、まして運用を止めるのは現実的ではありません。あるタイミングからLTS化して仕様の破壊的変更は止めた状態にし、裏でマイクロサービス化する必要がありそうです。
- 「学習コスト」
正直覚悟を決める以外にないのかなぁ...という気がします。 北見はバージョン管理をSVN⇒Gitへの移行した現場を経験したことがありますが、こればっかりはエンジニアとして努力すべき所であるように思えます。
初期の導入に際して他社さんのインターンを受ける、ノウハウを持った人を自社に招く、といった解決策があるでしょう。 現に、オイシックス様はMS主催のハッカソンに参加し、短期間でチーム全体のスキル底上げをしたそうです。
- 「何が正解かわからない」
長尾氏からの補足もありましたが、オイシックスで上手く行ったからといって、他社で上手く行くわけではないということを強調されていました。 サービスの規模や組織体制などは会社によって異なるため、自社にあった方法を模索する以外なさそうです。
理想と現実やその他の苦労
銀の弾丸たるソリューションはありません。
マイクロサービス化/k8s導入に取り組んだものの「思っていたのと違うな...」という点もあったようで...
いきなり多言語対応は厳しいでしょうね...
弊社プロダクト開発部ではC#を使用していますが、明日から全員Go言語のプロフェッショナルになれる訳ではありません。 仮にできたとして、レビューできるエンジニアに偏りができて属人化のリスクが生まれそうです。 もし我々のチームがマイクロサービス化へ舵をきったとしても、現実にはC#を使い続けるのではないでしょうか。
肝要なのは、
- 機械学習に頼りたいので、このサービスはpythonを採用する
- 大量のデータを高速でさばきたいので、このサービスではGoを採用する
といったように、意思と意図をもって技術選択をするということに思えます。
そしてそれ以外にも苦労はたくさんあったようで...
- 「なるべくシンプルに、できることから（だけ）やる」
- 「Kubernetes, コンテナ化自体にこだわりすぎない」
MSA化/コンテナ化してメリットがないサービスでは、やる意味は無さそうですね。
また、セッションでも言及があった通り「情報を集める時、まずは公式ドキュメントを見る」という習慣は、中級エンジニアへの登竜門のように思えます。 特にKubernetesは頻繁にバージョンアップをしているようで、二次情報はすぐに陳腐化してしまいます。
その上で、それ以外の情報媒体を有効に活用したい所ですね。
聴講者へのアドバイス
講演の締めとして、聴講者へのアドバイスを頂くことができました。
この中では特に「やったことのある人・会社に相談」「既存サービスの中で切り出しやすいところを試す」という点が肝要であるように思えます。 「餅は餅屋」という言葉もある通り、できる人に聞くのが上達のコツですし、いきなりスコープを広げすぎるのもリスキーです。
そして、最後には...
「一歩を踏み出す勇気が必要」
かっけぇ...
所感
個人的に本講演で最も重要だと感じたのは、最後のアドバイスにあった
やると決めて、本当にやること
ということです。
やるやる詐欺で手がつけられていないことが何と多いか...(超自戒)
普段の業務に追われて改善系のタスクは後回しにしてしまうことが多いですが、定期的に見直さないと、負債はたまっていくばかりです。
- 主業務の片手間でやる
- 業務効率化が評価の対象外
という条件だと失敗すると思われますので、本業として工数を割き、それを評価する決断をしたエンジニア・マネージャの方には敬意を払わずにはいられません。
さいごに
宣伝で恐縮ですが、レガシーシステムに関して、本ブログにLegacy Meetupの記事がございます。 buildersbox.corp-sansan.com レガシーシステム改善に興味のある方は、ぜひ併せてご覧ください。
