概要
- 2022年7月27日に開催されたQiita Night〜モノリスからの脱却って実際どうなの？マイクロサービス化について赤裸々に語る〜のイベントレポート
ライブ配信のアーカイブ
Qiitaユーザーの皆さまのレポート
コンテンツ
- LT
- 組織に浸透させるマイクロサービス思考 / @Yoyo-kikuchi
- 足場固めからやるマイクロサービス / @weakboson
- トークセッション / @Yoyo-kikuchi、@weakboson、@hanhan1978、@NMura3（モデレーター）
- どのようにマイクロサービス化を進めたのか？
- マイクロサービス化に伴う組織体制
- どんなプロダクト/組織がマイクロサービス化に向いているのか
LT
組織に浸透させるマイクロサービス思考
- スピーカー：@Yoyo-kikuchi
- 所属：ディップ株式会社 商品開発本部dip RoboticsDev Robo課 マネージャー
メモ
- マイクロサービス
- 手法の1つであり、扱うのは人であり、人が集まったチーム/組織
- マイクロサービス思考
- どんな技術でも使う人次第
- 重要になってくるのが思考の共有/カルチャー
- マイクロサービス思考3テーマ
- ドメイン駆動設計
- サービスを分割する境界線ってどのように判断するのか
- Eric Evansが2003年に提唱したソフトウェア開発手法
- 境界づけられたコンテキスト＝サービスを分割する境界線
- Conwayの法則
- システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう
- 独立したサービスを上手く動かすには組織構造の変革が必要
- 例：縦割り→横串
- アーキテクチャの変革を皮切りに壁を壊す！
- 自律性と協調
- 自律性
- 言われたことを言われたとおりにやるだけではなく、自分で考え行動する
- 協調
- お互いの立場・組織を超えて協働し連携する
- マイクロサービスでは各サービスごとにチームを配置し、そのチームに所有権を移譲しインテグレーションの速度向上を狙っている
- 所有権を移譲されるということは、サービスを健全に保つ責任を負う、これは自律性なしに成しえない
- 協調しないと単なる分割されたサービスになる
- 自律性
- ドメイン駆動設計
- やってみないとわからないので興味があるならJUST DO IT!
足場固めからやるマイクロサービス
- スピーカー：@weakboson
- 所属：株式会社カカクコム 食べログシステム本部 技術部 マイクロサービス化チームリーダー
メモ
- 食べログについて
- 日本最大級のレストラン検索・予約サイト
- 食べログマイクロサービス化の変遷
- マイクロサービス化に振り回された期
- サービスのAPI化・システムの分割を目的としてしまった（あるある）
- ある程度成功したが、結果的に大きな失敗も
- 「分散されたモノリス」アンチパターンになった
- 機能が複数のリポジトリをまたいで成立している
- ドメイン境界が正しく切り分けられていないことで複数のリポジトリのメンテナンスが必要に
- 共有DBのメンテナンスが煩雑
- 過渡期限定の予定が長期化
- テーブルの所有権が不明瞭でALTERで障害を起こすリスク
- 機能が複数のリポジトリをまたいで成立している
- マイクロサービス化は手段と悟り期
- サービスのAPI化・システムの分割は手段と再認識した
- 現状課題の可視化・分析
- PoCとPDCAを繰り返して、失敗は小さく早めに済ませる
- 改善の過渡期は長いので、レガシーなシステム基盤のままアプリケーション改善を始めると、過渡期が苦しくなり失敗しやすい
- ビジネス案件の成功が至上命題である開発チームにとって、ビジネスインパクトのない改善に、主体性を持って取り組むのは難しい
- マイクロサービス化に振り回された期
- 大規模なレガシーシステムを段階的に改善する取り組み
- STEP1：システムの変更容易性と変更安全性を高める
- STEP2：モノリスのレポジトリを小さく速く改善する
- STEP3：マイクロサービス分割
- マイクロサービス基盤カタログ
- 書籍「マイクロサービスアーキテクチャ」や他社事例、現状の課題から食べログに必要なシステム基盤をカタログ化する
- 小さく検証・運用をはじめて、うまくいったら導入を拡大していく
- システム基盤の改善から始めると、過渡期にもメリットが得られて嬉しい
- 冒険者と武器屋型モデル
- 事業開発を担う部門と技術開発を担う部門が、互いに主体性を持ちながら協調的に取り組む組織設計
- 開発エンジニア（冒険家）
- 基盤技術（武器）
- 技術部（武器屋）
- 事業開発を担う部門と技術開発を担う部門が、互いに主体性を持ちながら協調的に取り組む組織設計
トークセッション
スピーカー
- @Yoyo-kikuchi
- @weakboson
- @hanhan1978
- @NMura3（モデレーター）
セッションテーマ
- どのようにマイクロサービス化を進めたのか？
- マイクロサービス化に伴う組織体制
- どんなプロダクト/組織がマイクロサービス化に向いているのか
どのようにマイクロサービス化を進めたのか？
カオナビ
- 運営しているサービス
- タレントマネジメントシステム（人事システム）
- 複雑化したシステムに困っていた
- マイクロサービス化したいという移行
- マイクロサービスに向いているかどうか考えた
- マイクロサービス化は難しい
- →「リアーキテクチャリング」という形で進めている
- 敢えて「マイクロサービス」という言葉は使っていない
- 採用した技術
- アーキテクチャをCIでチェック
- 複雑さをチェックするツール
- 内部の構成をシンプルにするためのリファクタリングを実施
- 仕様の調査
ディップ
- 運営しているサービスについて
- バイトル、はたらこ、コボット
- マイクロサービスをどうやって進めていったか
- APIをマイクロサービス化
- 既存であったPHPのものをリプレイス
- 今はマイクロサービス化されたバックエンドを使っている
- APIをマイクロサービス化
- 採用した技術
- Amazon ECSとApp Meshを組み合わせて使用している
- 会社としてAWSを使っているのもあり
- API連携・認証
- まだ実装していない
- API連携gRPCを採用
- 障害が起きた時の対応
- SlackでBFFからどんな情報がきているか確認、たどって対応
- Excelを使っている
- Amazon ECSとApp Meshを組み合わせて使用している
カカクコム
- 運営しているサービスについて
- 食べログ
- マイクロサービスをどうやって進めていったか
- 基盤業務をAPI化していった
- 社内のオンプレ環境でバーチャルマシンで運用している。Kubernetesに移行中
- システム分割を進めていたが、一時停止中
- サービス分割しても運用していける基盤業務の構築に専念中
- Kubernetes管理プロダクト管理に移行予定
- 最初は新しくリポジトリをつくり、移行していった
- 基盤業務をAPI化していった
マイクロサービス化に伴う組織体制
- リアーキテクチャリングはCTO室が担当
- 丁寧なコミュニケーションや準備
- 実際のオペレーションメンバーの意見吸い上げなども
- 常日頃からコミュニケーションやリアクションをとるようにしている
- モノリスのデメリットとマイクロサービス化のメリットを提示
- ドメイン駆動設計、クリーンアーキテクチャに造詣の深い人をアサイン
- 事業継続の観点での説明
- 隔週のエンジニアのMTGでそれぞれのチームの採用技術の紹介をし、他のチームが使いたくなる、といったサイクル
【質問から】パネリストがお互いそれぞれに聞きたいこと
- 質とスピードのあるべき姿に沿ってやっていくといいのだろう
- ディップはパートナーさんの力を借りてやっているが、他の企業は正社員のみで進めている？
- パートナーさんに力は借りつつ、ではある
- 自律性は正社員のほうがあったりはするが、業務委託メンバーも意見を出してくれる
- ミッションに対して、達成するためのチームビルディングと計画を立てるが、採用がうまくいかない場合、業務委託メンバーの力を借りる
どんなプロダクト/組織がマイクロサービス化に向いているのか
- 当事者意識を持っているスクラムチーム（マイクロサービス化に関わらず）
- リアーキテクチャリングは開発者の幸せ、顧客の幸せのため（正しいアウトカム）
- 作った資料がオンボーディングで参照されるなど、わかりやすい指標でも成果が出ている
- やる、実行力
- 机上の空論で終わらせず、わくわくして取り組める組織
- 少人数で自律的に開発できる、Netflixでいうフルサイクルエンジニア？
- スペシャリストも賄えるだけの組織（フルサイクルエンジニアで賄えない部分）
- マイクロサービス化するだけの大きい組織、サービス
今後のイベントについて
Qiitaでは今後もエンジニアの皆さまにお楽しみいただけるイベントを開催予定です！
詳しくは以下をご確認くださいませ。