NIFTY Tech Day 2022 セシール事業におけるモノリシックアーキテクチャとの向き合い方

Copyright ©Cecile Corporation All Rights Reserved.
セシール事業における
モノリシックアーキテクチャとの向き合い⽅
株式会社セシール
技術推進グループ
丸⼭敦規

View Slide

⾃⼰紹介
Copyright © Cecile Corporation All Rights Reserved. 2
丸⼭敦規
株式会社セシール（出向 from NIFTY）
技術推進グループ
2015年にニフティに新卒⼊社。
2022年6⽉からシステム改善のためセシールへ
出向中。
趣味は電⼦⼯作と最近はじめた釣り、家庭菜園。

View Slide

TOPIC
セシールの紹介
システム課題
モノリスがもたらす開発遅延
アーキテクチャを考える
まとめ

View Slide

セシールの紹介

View Slide

株式会社セシール(Cecile Co, Ltd)
セシールは
総合通販事業の企業です
様々なジャンルのカタログを発刊
カタログ種類・・・6種類
カタログ発⾏数・・・4,000万部
セシールブランドのECサイトを展開
WEB会員数・・・ 830万⼈
⽉間PV数・・・ 3,300万PV
2022年3⽉時点

View Slide

セシールの歴史
1972
1983
1999
2004
2021
⾹川県⾼松市にて創業。
ストッキングを商品とし
て販売したところから
スタート！
インナーカタログ「セシ
レーヌ」創刊。約40年、
お客様に愛され続けてい
ます。
「セシールオンラインシ
ョップ」が開始。今では
売上の半数がWEBからの
ご注⽂です。
株式会社セシールとして
ニフティグループにて事
業開始。
メンズカタログ「メンズ
セシール」創刊。幅広い
年齢の⽅から⽀持されて
います。

View Slide

セシールの企業理念
お客様の声に常に⽿を傾け、
感動いただける商品・サービスを提供し、
全員経営で⽇本の発展に貢献する

View Slide

システム課題

View Slide

ビジネスを
加速させたい

View Slide

ビジネス加速によるシステム課題
世の中に追従するための開発量の増⼤
コンテンツ増⼤に伴う負荷問題
覚えなきゃいけないことが増えた

View Slide

ビジネス加速によるシステム課題
世の中に追従するための開発量の増⼤
コンテンツ増⼤に伴う負荷問題
覚えなきゃいけないことが増えた
現在のアーキテクチャでは
スピードを出せない

View Slide

セシールのアーキテクチャ
モノリス（⼀枚岩）
顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
（ECや管理）
App
• 単体アプリケーションで動作
• 共有DBが鎮座している
• 規模の⼤きい1チームで管理
※単体で動作可能なサービス
（機能）の集合をModuleと呼び
ます。

View Slide

モノリスがもたらす
開発遅延

View Slide

モノリスとマイクロサービス
モノリスとセットで紹介されることが多いマイクロサー
ビスアーキテクチャ(MSA)と⽐較します。
顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
（ECや管理）
App
商品
Module
App
顧客
Module
App
注⽂
Module
App
注⽂
Module
App
検索
Module
App
発注
Module
App
UI
（ECや管理）
DB DB DB
DB DB DB
モノリスマイクロサービス

View Slide

顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
（ECや管理）
App
商品
Module
App
顧客
Module
App
注⽂
Module
App
注⽂
Module
App
検索
Module
App
発注
Module
App
UI
（ECや管理）
DB DB DB
DB DB DB
開発速度
組織構造
スケーリング
技術スタック
⼀貫性の担保
運⽤
開発の範囲が明確で迅速
開発が複雑になり遅い
サービス毎にチーム
肥⼤化した単⼀チーム
アプリ単位でスケール可
全体スケールのみ
複雑
シンプル
担保しにくい
担保しやすい
管理対象が増加
管理の⼿間が少ない

View Slide

顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
（ECや管理）
App
商品
Module
App
顧客
Module
App
注⽂
Module
App
注⽂
Module
App
検索
Module
App
発注
Module
App
UI
（ECや管理）
DB DB DB
DB DB DB
開発速度
組織構造
スケーリング
技術スタック
⼀貫性の担保
運⽤
開発の範囲が明確で迅速
サービス毎にチーム
肥⼤化した単⼀チーム
アプリ単位でスケール可
全体スケールのみ
複雑
シンプル
担保しにくい
担保しやすい
管理対象が増加
管理の⼿間が少ない
開発が複雑になり遅い
無視できないほど
顕著になってきた

View Slide

セシールが悩まされている
モノリス起因の３つの遅延

View Slide

開発速度の遅延
過度な不安が助⻑される
実際の修正範囲は狭く対応もすぐ終わる。
修正時間に対しての調査時間が⻑い傾向。
全部確認しないと
安⼼できない・・・
顧客
商品
注⽂
発注
検索
請求
Module
App
確認範囲
修正範囲
開

View Slide

意思決定の遅延
最悪を想定した⾒積もり
不安になると⾃信を持った回答がすぐにできなくなる。
さらに⾒積もりが過剰になる傾向。
開
それは
すぐには判断
できないな…
顧客
商品
注⽂
発注
検索
請求
Module
App
確認範囲
修正範囲
（調査）時間もかか
りますし。
やってみないと分か
らないです。

View Slide

技術者育成の遅延
仲間が増えたのに
仲間が増えても業務理解に時間がかかってしまい、
実際の作業にアサインされるまでのリードタイムが⻑い。
顧客
商品
注⽂
発注
検索
請求
Module
App
必須業務理解
開
新
何ヶ⽉
かかるんだろ
教える時間
確保できるかな

View Slide

肥⼤化したモノリスは
「過度な不安」
を招き、様々なスピードが落ちる

View Slide

モノリスを脱却する際の⼼構え
「アーキテクチャに銀の弾などない」
新しいアーキテクチャのメリットを得ると同時
にデメリットに向き合うということになります。
デメリット対策をきちんと考えておくことが重
要になってきます。

View Slide

アーキテクチャを
考える

View Slide

現セシールの体制
少ない社内エンジニアで⾜らないリソースを業務委
託で補っている
A
D
B C
X
共有DB
Module
App
アーキテクチャ
体制
要件整理
発注/納品
開開開
開開開
社内開発チーム
A開発依頼
B開発依頼
X開発依頼
業務委託先
…

View Slide

MSAを導⼊した場合の体制
体制を変えずにMSAを導⼊した場合
体制
A
Module
App
B
Module
App
X
Module
App
DB
DB
DB
・
・
要件整理
発注/納品
開開開
開開開
A開発依頼
B開発依頼
X開発依頼
業務委託先

View Slide

体制を変えずにMSAを導⼊した場合
体制
A
Module
App
B
Module
App
X
Module
App
DB
DB
DB
・
・
要件整理
発注/納品
開開開
開開開
A開発依頼
B開発依頼
X開発依頼
業務委託先
結局全サービスを
覚えないといけない状況
（=メリット薄い）

View Slide

理想としては1チーム=1サービスとしたい
（が、分けすぎもオーバヘッドが増えるので組織にあった塩梅を探る）
体制
A
Module
App
B
Module
App
X
Module
App
DB
DB
DB
・
・
A開発依頼
B開発依頼
X開発依頼
開開開
サービスAチーム
開開開
サービスBチーム
開開開
サービスXチーム
・
・

View Slide

業務委託と相性悪い？
MSAへの移⾏⽅法は？
周囲の理解を得るには？
MSAやれるかな？
セシール内で起こった議論

View Slide


View Slide

内製化に拘る必要はない
開開開
内製T
開
パッケージ導⼊T
サービスの特性を考えて最適な体制を取ること
ができる。
開
業務委託T
A
Module
App
選定
B
Module
App
C
Module
App
業務委託先
開
発注

View Slide

パッケージ導⼊を主とするチーム体制
以下のような性質のサービスを扱う
• 機能性/分離性重視
• 会社の独⾃性は不要
• 重要度が低い
他サービスとの連携性を重視して選定
開
パッケージ導⼊T
A
Module
App
選定

View Slide

開
業務委託T
B
Module
App
開
発注
業務委託先
従来の業務委託を主とするチーム体制
• 安定性重視
• 会社の独⾃性は必要
• 重要度が⾼い
他サービスとの連携性を重視して選定

View Slide

開開開
内製T
C
Module
App
内製での開発を主とするチーム体制
• スピード/変更容易性重視
柔軟にスピードを出すことが求められる

View Slide

開開開
内製T
C
Module
App
内製での開発を主とするチーム体制
• スピード/変更容易性
柔軟にスピードを出すことが求められる
セシールでは
⼀番作るのが難度が⾼いT
頑張って作る必要がある💪

View Slide


View Slide

ストラングラーパターン
顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
App
商品
Module
App
顧客
Module
App
注⽂
Module
App
注⽂
Module
App
検索
Module
App
発注
Module
App
UI
DB DB DB
DB DB DB
顧客
Module
App
注⽂
Module
App
UI
DB
DB
顧客
商品
注⽂
発注
Module
GW
GW GW
図の様に徐々に移⾏させる⼀般的な⼿法。
少しずつサービスを分離でき、メンバーが少し
ずつイメージしやすく⼤きな選択ミスをしない
利点もあります。
Phase1: GWを設置 Phase2: 徐々に移⾏ Phase3: 完全に移⾏
共有DB

View Slide

ストラングラーパターン
顧客
商品
注⽂
発注
検索
請求
共有DB
Module
UI
App
商品
Module
App
顧客
Module
App
注⽂
Module
App
注⽂
Module
App
検索
Module
App
発注
Module
App
UI
DB DB DB
DB DB DB
顧客
Module
App
注⽂
Module
App
UI
DB
DB
顧客
商品
注⽂
発注
Module
GW
GW GW
場合によってはPhase2段階が⻑く続く場合があり
ます。「スピード」を出すという⽬標が既に達
成されていればPhase3は⽬指さなくてもいいかも
しれません。
Phase1: GWを設置 Phase2: 徐々に移⾏ Phase3: 完全に移⾏
共有DB

View Slide


View Slide

短期的な成果を⽬指す
アーキテクチャの変更には様々なステークホル
ダーからの協⼒が必要不可⽋です。
簡単に分離できて成果を出しやすいサービスを
マイクロサービス化させてポジティブなイメー
ジを持ってもらうことをまずは⽬指しましょう。

View Slide

短期的な成果を⽬指す
参考までに、セシールでは社内外からの要望が
⼤きく⽐較的分離が簡単な「⼝コミ」機能の分
離から検討を始めています。
⼝コミ
Module
App
UI
DB
顧客
商品
注⽂
発注
Module
GW
共有DB

View Slide


View Slide

MSAに必要以上に拘らない
MSAはあくまでスピードを上げるための⼿段
MSAに拘らず
• モジュラモノリス
• ミニサービス
を採⽤することも考えましょう。

View Slide

補⾜：モジュラモノリス・ミニサービス
Shopify Engineer.「Deconstructing the Monolith: Designing Software that
Maximizes Developer Productivity」https://shopify.engineering/deconstructing-
monolith-designing-software-maximizes-developer-productivity

View Slide

正解はない
組織にあった⽅法を
少しずつ探りながら変えていくことが⼤切

View Slide

まとめ

View Slide

本⽇の発表
• セシールではモノリシックアーキテクチャを
採⽤していたがビジネスを加速させるために
アーキテクチャを変える必要が出てきた
• アーキテクチャに正解はなく、その会社に最
適なアーキテクチャを模索する必要がある

View Slide

最後に

View Slide

セシールでは
⼀緒に働く仲間を募集中です！！

View Slide

「Il offre sa confiance et son amour」
（愛と信頼をお届けする）

View Slide

NIFTY Tech Day 2022 セシール事業におけるモノリシックアーキテクチャとの向き合い方

NIFTY Tech Day 2022 セシール事業におけるモノリシックアーキテクチャとの向き合い方

ニフティ株式会社

More Decks by ニフティ株式会社

Other Decks in Programming

Featured

Transcript