DeveloperSummit 2018 Cassandra, Kubernetesによる大規模データ基盤の仕組みと苦労 / Developer Summit 2018 Infrastructure by Cassandra and Kubernetes

株式会社ブロードリーフ
松本宏紀
2018.07.27
Cassandra x Kubernetesによる
大規模データ基盤の仕組みと苦労
#devsumiC C-6

View Slide

Copyright © Broadleaf Co., Ltd. All Rights Reserved. 1
自己紹介
松本宏紀
株式会社ブロードリーフ基盤開発部
• サービス開発、システムトラブル対応支援、開発ツール作成、技術的な支
援などなど・・・。なんでも屋さん。
• Java・DB全般がメイン。
• 北海道札幌市で働いてます。札幌から出たくない引きこもりです。

View Slide

本日のテーマ
RDBMS
オンプレ環境
Cassandra
抜本的アーキテクチャの見直し
Kubernetes(GCP)

View Slide

背景
引用：https://www2.broadleaf.co.jp/recruit/business/index.html

View Slide

背景
主に扱っているデータ
車の仕様車の部品仕様
車
車・部品の流通

View Slide

背景
価格の改定等の細かい情報も合わせると…
20億点以上のデータ
参考：
※1・・・ https://www.broadleaf.co.jp/products/auto/sfns/ より引用。
※2・・・ https://www.broadleaf.co.jp/products/auto/pmns/ より引用。
※3・・・ http://v4.eir-parts.net/v4Contents/View.aspx?template=ir_material_for_fiscal_ym&sid=48222&code=3673 より引用。
48万点以上
(※1)
4億6,000万点以上
(※2)
約1,682万台
(※3)
2億/年
(推定)

View Slide

背景
約30,000社に業務システムの導入
多くのデータを蓄積
約1,682万台約4台に1台の車両データを蓄積
日本でNo.1 シェア

View Slide

背景
さらなる成長、さらなる機会を
データを基軸としたサービス展開を強化
海外まで
より多くのデータを蓄積しつつ、
分析等活用しやすい形でデータを保持したい

View Slide

本日のテーマ
RDBMS
オンプレ環境
Cassandra
抜本的アーキテクチャの見直し
Kubernetes(GCP)
車といった多くの属性を持つデータモデル、
関連情報が多くあるデータモデルをより高速に、大量に扱いたい

View Slide

Copyright © Broadleaf Co., Ltd. All Rights Reserved.

9
Cassandraを選択した理由
RDBMSのデータをクラウド上に全部上げるのは無理
商品構成 A
お客さま環境
BL オンプレ環境
DB Server
AP Server
Client Apps
商品構成 B
お客さま環境
DB Server
AP Server
Client Apps
・速度要件が厳しい
・オンプレでは保守難しい
AWS
DB Server
AP Server
RDBMS 数十以上のインスタンスでの運用→コスト大幅増

View Slide

Cassandraが相性が良かった
リニアにスループットがあがるもの
簡単に分散できるもの
コストが爆発していかないもの
レプリケーションが可能なもの
(大量データにおける)CRUDが速いもの
RDBMS Cloud Datastore
運用・開発しやすいもの

Cloud Spanner
Cloud Spanner
Cloud Spanner
Cloud Spanner
Cloud Spanner
Cloud Spanner
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra
Cassandra

View Slide

Cassandraは使いにくい
伝票
顧客属性での絞り込み
部品属性での絞り込み
車属性での絞り込み
日付毎での絞り込み
汎用ラベルでの絞り込み
データは、様々な視点で見たい。新しい気づきを得たい。
探しにくいものを、探しやすくするというシステムの根幹を
揺るがす問題。

・Cluster Key ?
・Secondary Index ?
・Custom Table ?
→設計しんどい＆変えづらい

View Slide

Cassandra x Elasticsearch
Elasticsearchがお仲間になりました。
kafka
Compute Engine
Data Apps
Container Engine
API
Container Engine
Users
Cassandra
Compute Engine
Elasticsearch
Compute Engine

View Slide

RDBMS
伝票ヘッダ
伝票明細
1
N
Cassandra
伝票ヘッダ List<明細>
Elasticsearch
/伝票 {
ヘッダ: { … },
明細： [
{ … }, {… }
]
}
一回の操作で更新・取得する
伝票全体で検索できるようにする
すぐに見るもの、後で見るものを区別する

更新操作取得
柔軟検索

View Slide

Cassandra
Elasticsearch
Kafka
Spring Boot
or
Go Apps
Angular
Kafkaまで更新できたら応答返す
一般的には・・・下記構成と思います。
※メッセージ駆動型
kafka
Cassandra
Elasticsearch
更新情報蓄積＆バラまき
kafka使って非同期連携

BigQuery
trigger
概念的にはCQRSに近い構造

View Slide

集計処理をしようと思うと、Cassandraきつい。
DC1
node2
node1
node5
node3
node4
集計処理
日次集計
ユーザー数
CPU: 90%
CPU: 100%
CPU: 50%
CPU: 70%
CPU: 70%

分析等をするために、全データ対象、広範囲の集計は行えないと
意味が無い。

View Slide


Data Center
Users
16
DC1
node2
node1
node5
node3
node4
DC2
node2
node1
node5
node3
node4
Batch Jobs
replication
LOCAL QUORUM LOCAL XXX
DCを別にして、LOCAL QUARUMでのアクセスにより、
通常業務上での負荷と、バッチ系処理を別々に制御する
ことが可能。
負荷の高い処理は、別のデータセンターで実行する

View Slide

GCP x Kubernetes
アプリケーションが追い付かない

DB
AP Server ボトルネックの発生！！！

View Slide

GCP x Kubernetes
Google Kubernetes Engine (GKE)
Kubernetesでスケールも容易に

StatefulSet B
Google Cloud Load Balancing ( GCLB )
StatefulSet A
POD1 POD1 POD2
ingress.yaml
- static ip
- ssl-cert
- url mapping
service.yaml
- name
- port
statefulset.yaml (deployments)
- replicas
- cpu, memory (request,limits)
- docker image
- health check
- volume
オートスケールを使わなくても、
$ kubectl scale sts A --replicas=4
というだけでスケールアウト可能。

View Slide

GCP x Kubernetes
Develop IT Staging Production
Google Container Registry
App
App：1.2-snapshot App:1.2-snapshot App:1.2 App1:2
configmap/secret configmap/secret configmap/secret
自動デプロイがとても簡単
全てがGitlabのリポジトリと連動
Gitlab

Gitlab Runner での自動デプロイ
・ソースの追跡性の確保。
・履歴としてimageの蓄積
・Gitlab Container Registryにも一部登録
docker-compose
test + build + push
自動自動半自動
手動(pull)
Gitlab Runnerでのデプロイ
( いつかはSpinnaker )
applicayion.yaml
Prometheus
monitoring

View Slide

理想
20
こまったこと：人がスケールしない
開発する人が追い付かない

自社管理チーム

契約管理チーム

在庫管理チーム

現実はぐちゃぐちゃになる。
理由は、業務要件でチームを分けたためマルチベンダー体制による
分散リポジトリの超平行開発に伴うカオスが生まれる
現実
自社管理サービス契約管理サービス在庫管理サービス
BL：業種Aチーム
A社 B社 C社 D社 E社 F社 BL
BL：業種Bチーム
20
3
11

View Slide

こまったこと：人がスケールしない
システム・アーキテクチャだけではなく、
開発全体の最適化を進める

プロセス
チーム
(組織)
システム
アーキテクチャ
マイクロサービス

View Slide

Angular
Mock？MockBean？SpyBean？
Kubernetes?
maven？
git？Markdown？
22
こまったこと：メジャーな技術じゃなかった
Ｄｏｃｋｅｒ？ Cassandra？
Elasticsearch？
多くの人は・・・
• 公式サイトは読まない。
• 英語は読まない。
現実は厳しい。
GCP？
dockerでの環境構築手順をvirtualboxで行う際の手順
を教えてください。 ( ？？？ )
Angularとかググっても英語のサイトしか出てこない
メジャーじゃないフレームワークなんて無理ですよ。
Cassandraのデータ設計は無理です。
ブロードリーフさんでやってください。
そもそも、そんな技術を使える人が、
そんなにいないという事実

View Slide


23
こまったこと：メジャーな技術じゃなかった
JIRAでのQA→ SlackでのQA
Confluenceを全ベンダーと共有
よりスピーディなコミュニケーションと情報蓄積を進める

View Slide

まとめ
RDBMS
オンプレ環境
Cassandra
もの足りない時は、他の手を探す。
スケールできる構造に、システム全体を見直す。
コミュニケーションも最適化していく。
Kafka
Elasticsearch
Kubernetes
JIRA Confluence
データを扱う = データ + α の知識が必要。
Kubernetes(GCP)

View Slide

Developer Summit 2018 Summerのテーマ
データが拡張する人や社会、これからのエンジニアの道標
テクノロジーがあらゆる業界に影響を与える時代、「データは新しい資源」と呼ばれ
るほどデータの活用は企業活動の要となっています。AIは、人間を脅かすものでは
なく、人間の可能性を拡張するもの（拡張知能）として、注目は留まるところを知り
ません。
AIやデータを活用するためのデータサイエンスの知見、大規模データやトラフィック
処理のためのインフラの構築・運用、IoTやブロックチェーンなど新テクノロジーを活
用したサービス開発など、まさにデータというエリアは、エンジニアの持つさまざま
スキルが生きるフロンティアと言えます。
データ活用が人と社会の可能性を拡げている時代。デブサミ夏2018では、データ
に向き合うエンジニアの知見や試行錯誤のシェアを通じて、これからのエンジニア
の役割と生き方を模索します。

View Slide

インフラ
アプリケーション
サイエンス
26
まとめ
データ
学習
サービス
分析
データを中心とした技術・体制・コミュニケーション
運用

View Slide

でも、何より・・・
変化を
楽しく
受け入れる

View Slide

DeveloperSummit 2018 Cassandra, Kubernetesによる大規模データ基盤の仕組みと苦労 / Developer Summit 2018 Infrastructure by Cassandra and Kubernetes

DeveloperSummit 2018 Cassandra, Kubernetesによる大規模データ基盤の仕組みと苦労 / Developer Summit 2018 Infrastructure by Cassandra and Kubernetes

Broadleaf Co., Ltd.

More Decks by Broadleaf Co., Ltd.

Other Decks in Technology

Featured

Transcript