とらのあな抽選会を支えたマイクロサービス_20210611_TechDay#1_1

Copyright 2021 Toranoana Inc.
とらのあな抽選会を支えた
マイクロサービス
大場祥哉
虎の穴ラボ株式会社
1

名前：大場祥哉 
担当業務：EC開発(SEO)、スクラムマスター 
業務使用言語：Java、Kotlin 
趣味：筋トレ 
自己紹介 
2

同人誌を取り扱うオタク向けECサイト🐯 
3

● お買い物をすると、無料で一回抽選ができる。 
● 当たりが出るとポイントがもらえるキャンペーン。 
2021年GW企画ポイント大抽選会  
4

5

VPC
フロント/API/カートサーバ
バッチ/管理サーバ....
AWSでマイクロサービス設計例 
DB
とらのあなEC
RDS
6
Aurora 
Serverless 
APIサーバ
ECS
Fargate 
コンテナ 
EC2

● マイクロサービスの基礎  
● マイクロサービスのメリット 
● マイクロサービス化の前に 
● とらのあな通販での抽選企画 
● AWSを用いた構成例 
● まとめ 
アジェンダ 
前半 : マイクロサービス
後半 : 抽選企画 & AWS
7

マイクロサービスの基礎
知ってるって人は聞き流してね
8

◆特徴 
● 大きな1つの機能を1つのサービスとして提供する設計。 
● 機能把握が難しい。機能の結びつきが強く変更しにくい。 
 
マイクロサービスの対義語（モノリス） 
決済
顧客管理商品展示
9

マイクロサービスとは？ 
決済
顧客管理商品展示
◆特徴 
● 依存性のない小さなサービスを組み合わせて1つのサービスを作る手法。 
● 機能の追加や変更が容易で、コンテナサービスと相性が良い。 
10

なぜ、コンテナサービスと相性が良いか？ 
 
コンテナ技術はアプリ(機能)ごとにコンテナを作成し、 
それを連結させることで1つのサービスを組み立てる事が出来る。  
　　　　　　マイクロサービスの考え方と同じ！ 
 
コンテナ
（プロキシ）
コンテナ
（Webサーバ）
コンテナ
（DBサーバ）
顧客管理
商品情報
コンテナコンテナコンテナ
決済
コンテナコンテナコンテナ
11

アジャイル開発とも相性が良い 
● 機能単位での変更となるため、変更規模が小さい 
○ テスト規模も小さくなる 
○ 1スプリントに合わせた頻度でリリースしやすい 
○ スケジュールのズレが発生しにくい 
12

マイクロサービスのメリット 
13

● 技術異質性・・・ 
● 回復性・・・ 
● デプロイの容易性・・・ 
● スケーリング・・・ 
● 組織面との一致・・・ 
● 合成可能性・・・ 
● 交換可能にするための最適化・・・ 
参考：Sam Newman 著, 佐藤直生訳, マイクロサービスアーキテクチャ,オライリー・ジャパン 2020年 
マイクロサービスの７つのメリット 
 
14

決済 
顧客管理  商品展示 
● マイクロサービス毎に異なる技術が利用できる。 
 
1.技術異質性 
15
EC2 Instance  EC2 Instance  EC2 Instance

● 新しい技術が生まれる理由・・・ 
○ より効率的に！より安全に！より簡潔に！
 
● 最新技術のメリットを享受したい 
○ Java から Kotlin へ 
○ EC2 から AWS Fargate へ 
○ RDS PostgreSQL から Aurora Serverless へ
 
 
最新技術の活用 
16

EC2 Instance  EC2 Instance  EC2 Instance 
レコメンド 
顧客管理  決済機能 
2.回復性 
● フェールソフトなシステム構築ができる。 
 
17

● 障害時でも主要サービスは継続したい 
○ モノリスな設計 
■ 復旧時間：長 (再リリース)  
■ 影響範囲：大 
○ マイクロサービスで縮退運行が可能な設計  
■ 復旧時間：短 (サーバー停止)  
■ 影響範囲：小  
障害時の縮退運行 
18

レコメンド 
顧客管理  決済 
3.デプロイの容易性 
● 変更が加わったマイクロサービスだけをデプロイできる。 
19

決済 
顧客管理 
商品展示 
4.スケーリング 
  ● 特定のサービスだけをスケールアウトできる。 
20

負荷予測の重要度低下 
 
● スケール機能の活用により負荷予測の重要度が下がる 
○ 新規サービスなど負荷予測が難しい  
■ リリース後の使用状況からスケールアウト  
■ 余裕をもたせたスペックでリリースし、徐々にスケールダウンも可能  
スケールアップ  スケールダウン 
21
EC2 Instance  EC2 Instance  EC2 Instance 
EC2 Instance

● 小規模コードは理解しやすいので、生産性が高い。 
● 小規模コードを少人数チームで変更。コミュニュケーションも楽。 
決済
顧客管理商品情報
5.組織面との一致 
22

決済 
顧客管理  商品情報  決済 
6.合成可能性 
● 別サービスで機能の再利用が可能 
サービスA サービスB
23
EC2 Instance  EC2 Instance  EC2 Instance  EC2 Instance

● サービスを跨いで機能を再利用できる。
 
○ 相互送客、サービス跨ぎのレコメンド、ログイン機能統一....
 
イベント作品取置きオンライングッズ作成
クリエイター向けプラットフォーム
通販サイト
サービス間での再利用 
24

決済 
顧客管理  商品情報 
移行
決済
7.交換可能にするための最適化 
 
● システム移行時の作業コストが低い。 
 
25
EC2 Instance  EC2 Instance  EC2 Instance  EC2 Instance

● 大規模なシステム移行が行われる際の開発負担を軽減 
○ コツコツとマイクロサービス化を積み上げる 
■ システム移行対象の削減 
■ 書き換えるコード量が減る 
26
将来的なシステム移行に備える

● 技術異質性・・・マイクロサービス毎に異なる技術が利用できる。 
● 回復性・・・フェールソフトなシステム構築ができる。 
● デプロイの容易性・・・変更が加わったマイクロサービスだけをリリースできる。 
● スケーリング・・・特定のサービスだけをスケールアウトできる。 
● 組織面との一致・・・小規模コード＝小規模チームで変更。 
● 合成可能性・・・機能の再利用ができる。 
● 交換可能にするための最適化・・・システム移行時の作業コストが低い。 
 
参考：Sam Newman 著, 佐藤直生訳, マイクロサービスアーキテクチャ,オライリー・ジャパン 2020年 
マイクロサービスの７つのメリット 
27

マイクロサービス化の前に 
28

マイクロサービスで使用する技術選定 
 ● すでに利用している技術＋今後採用していく予定の技術 
● 最新技術を色々試せるメリットはあるがレビューできる人が少ない 
選定した技術選定理由
言語 Kotlin Java を利用中。Java との相互運用性。
DB PostgreSQL PostgreSQL を利用中。
クラウドサービス AWS オンプレ環境から AWS環境へ移行中。
AWSサービス Aurora Serverless
+ AWS Fargate
Aurora Serverless の活用
コンテナ技術の活用
29

マイクロサービス化の際に決めなかったこと 
● マイクロサービスの具体的な再利用計画 
○ ただし、拡張しやすい設計は必要 
○ 開発した機能の約60%は使われない 
■ 使われない場合は停止。コスト削減やリソース開放 
○ 再利用できれば、開発コストが抑えられる 
30

● 主に機能追加の場合に、マイクロサービス化を進める。 
 
とらのあなEC
伝票管理
顧客管理
カート
購入機能
キャンペーン機能
お知らせ
　　新規機能
抽選
とらのあな通販におけるマイクロサービス化の対象(1) 
31

● 負荷軽減のために、機能の切り出しとデータベース分割を行う。 
  とらのあなEC 
伝票管理 
顧客管理 
カート 
購入
機能  特典 
お知らせ
とらのあな通販におけるマイクロサービス化の対象(2) 
　
機能の切り出し
 
お知らせ 
DB  
マスタDB 
(伝票、顧客、商品、特典、
お知らせ)  　　　　　データベースを分割 
32

● マイクロサービス設計の際に粒度を小さくしすぎる(ナノサービス) 
○ API通信が大量に発生しパフォーマンス低下を招く。 
とらのあなEC
伝票管理
顧客管理
カート
購入機能
キャンペーン機能
お知らせ
抽選実行
抽選期間管理抽選予算管理
アンチパターン 
33
API通信 API通信
API通信

ここまでのまとめ 
● マイクロサービス化により、様々なメリットを享受できる 
○ 特に最新技術の利用と他サービス連携での再利用が魅力的✨ 
● マイクロサービス化の前にすること 
○ マイクロサービス化の対象 
○ 現在利用している技術と将来を見据えての技術選定 
34

とらのあな通販 
抽選企画について 
〜質問受付中〜
35

抽選企画の内容 
● 注文完了後に自動的に抽選が行われポイントバック(0% ~ 100%) 
○ マイクロサービスの再利用が可能 
● 企画に使える予算を超えてはいけない (1,000万円分のポイントバック) 
○ ２週間で新規機能追加 
○ 既存のECサービス、マイクロサービス側にも機能が無い  
36

設計について(新規機能と実装箇所分担) 
機能名説明結合度実装箇所
開催期間判定開催期間外なら抽選しない低 EC & マイクロサービス
予算超過判定予算超過したら抽選しない低マイクロサービス
抽選処理抽選結果を返す(0 ~ 100%) 低マイクロサービス
予算計上注文金額 * 抽選結果(%)を記録低マイクロサービス
● 開催期間判定は両方で実装 
○ 企画終了後はEC→マイクロサービス側へ不要なリクエストを投げない設計にした  
37

注文内容確認画面
注文完了画面
抽選実行
合計金額算出
カート画面
開催期間チェック
ECシステム
(バックエンド)
(APIサーバ)
抽選実行
予算計上
開催期間チェック
当選結果記録
抽選結果描画
顧客(フロント)
予算チェック
抽選結果記録
抽選企画の処理フロー 
38

結合
テスト
設計開発
単体
　テスト
設計開発
設計開発
リリース
バックエンド担当
マイクロサービス担当
フロント担当
リリースまでの並行開発 
　単体
　テスト
単体
　テスト
39

マイクロサービス環境 
言語  Kotlin  v1.3.70 
フレームワーク  Ktor  v1.3.2 
ORM  Exposed  v0.24.1 
コネクションプール 
ライブラリ 
HikariCP  v2.7.8 
● Ktor、Exposedは、JetBrains製のライブラリ 
40

41
 
 
 
 
 
 
 
　 
VPC
AWSを用いた構成例 
ECR
push 
pull  Aurora 
Serverless 
DB 
APIサーバ
ECS
Fargate 
コンテナ 
RDS

Amazon Elastic Container Registry 
● 完全マネージド型のコンテナレジストリ 
○ インフラ管理、ソフトウェアのインストールが不要 
● かんたんにコンテナイメージの保存、管理、共有、デプロイができる 
○ プライベートなリポジトリの作成も可能 
 
push 
ECR https://aws.amazon.com/jp/ecr/
42

AWS Fargate 
● ECSの起動オプションの一つで、サーバレスなコンテナ実行環境
○ コンテナ実行が楽。コンテナイメージを指定するだけ
● コンテナを実行していない間は課金されない
https://aws.amazon.com/jp/fargate/
pull 
push 
ECR 
ECS 
Fargate
43
コンテナ

Amazon Elastic Container Service  
● コンテナのオーケストレーションを行うAWSサービス
○ デプロイメント、管理、スケーリングなどを自動化
● FargateとEC2とEXTERNALの3つのコンテナ起動タイプを選べる
○ EXTERNALはECS Anywhereの追加に伴い最近追加された
https://aws.amazon.com/jp/ecs/
44

タスク
ECS 
Fargate
タスク定義 
・Fargate互換 
・イメージ 
・CPU 
・メモリ 
クラスター  
サービス［タスク数:2］  
タスク
コンテナ
コンテナ
ECR 
45

EC2 とFargateの違い 
EC2 Fargate
課金インスタンス起動中コンテナ起動中
OSやミドルウェア設定必要不要
インスタンス、クラスター管理必要不要
● コンテナ実行環境として利用する場合はFargateが良い 
○ 低コストかつ運用管理の負担が低い 
46

Lambda と Fargate の違い 
● Lambdaは制約が多い 
■ 実行時間の上限が15分 
■ デプロイパッケージサイズの上限が250MB 
 
47
Fargate Lambda
課金体系コンテナ実行中コード実行中
環境構築不要不要
利用シーン継続的に実行される処理イベント駆動

Amazon Aurora 
  MySQL 及び PostgreSQL と互換性のあるリレーショナルデータベース。 
１.速くて 
● 標準的な MySQL データベースと比べて最大で 5 倍高速 
● 標準的な PostgreSQL データベースと比べて最大で 3 倍高速 
2 .安全 
● ３つのAZに分散され、レプリケーションされる 
● ディスク障害に対するデータベースの耐障害性が高い 
  https://aws.amazon.com/jp/rds/aurora/
48

Amazon Aurora Serverless 
 
以下のシーンにおいてAuroraよりも費用対効果が高い 
● アクセス頻度が低い or 断続的 
● 予測できないワークロード 
なぜ？ 
● 数分間アイドル状態の場合一時停止する 
● ワークロードに応じて、スケールアップ or スケールダウン 
上記機能により自動で停止やスケールの変更を行う 
https://aws.amazon.com/jp/rds/aurora/serverless/
49

Container Insights 
 
抽選期間中のFargateのメトリクス 
50

Fargateのコスト 
● 合計: 8,870円 
○ vCPU: 6,336円 
○ メモリ: 2,534円 
 
トータルコスト = vCPU費用 + メモリ費用 + 通信費
vCPU費用 = タスク数 * vCPU(数) * 料金単価 * 稼働時間(h)
メモリ費用 = タスク数 * メモリ(GB) * 料金単価 * 稼働時間(h)
通信費 = 12日間の通信量が1.6MBだったため省略
vCPU = 2(タスク) * 2(vCPU数) * 5.5円(単価) * 24時間 * 12日 = 6,336
メモリ = 2(タスク) * 8(メモリ) * 0.55円(単価) * 24時間 * 12日 = 2,534
6,336 + 2,534 + 0 = 8,870円 
メモリ 8GB
vCPU 2
タスク数 2
稼働時間 12日(288h)
価格表　※2021年6月4日時点
 
1 時間あたりの vCPU 単位 0.05056USD = 約5.5円
 
1 時間あたりの GB 単位 0.00553USD = 約0.55円
 
51

Aurora Serverlessのコスト 
● Aurora Serverlessの費用：6,223円 
○ ACUという独自の単位 ( Aurora キャパシティーユニット ) 
○ 0.10USD/ACU 時間 
○ 2 ACU x 288 h x 0.10 USD = 57.6 USD = 6,223円 
 
 
 
※通信料も発生しますが、12日間で1.6MB程度だったので省略。 
52

Elastic Container Registryのコスト 
● ECR : 0円（無料枠内に収まった） 
53

システム費用合計：15,093円 
○ Fargate... 8,870円  
○ Aurora Serverless… 6,223円 
○ Elastic Container Registry... 0円 
 
※顧客へのポイントバックの予算1,000万とは別枠 
GW抽選企画に掛かったシステム費用 
＜常に最小ACUだった
＜過剰スペック
54

抽選企画の効果について 
● 抽選期間中のリピート購入率の向上
抽選実施期間と抽選未実施期間でリピート購入率を比較
※リピート購入率 = リピート購入数 / 全体購入数
55

実はAurora Serverless の利用シーンに合致してない 
● 使用頻度が低い、断続的、または予測不能なワークロード向けのシンプルでコ
スト効率の良いオプション 
○ 12日間継続的にリクエストが発生 
■ アイドル状態→自動起動によるコストカットが不可 
■ アイドル状態からの復帰に時間がかかる問題 
■ コネクションプールを使っていた 
56
Aurora Serverless v2 では起動時間問題が解消されるらしいので期待

● GW抽選企画が話題に上がらない、Twitterでもシェアされない 
○ リリース後急遽シェアボタン設置、OGPに当選結果を表示 
失敗談 
57

● 約２週間でマイクロサービスを再利用し新機能追加ができた
● 期間限定利用のコードでモノリス側を汚さずに済んだ
● 利用した分しか課金されないためコスト計算がしやすい
● 障害発生無し。長期稼働や複数サービスに跨った場合は怪しい
● オートスケールの活用でコスト削減が見込めた
● 今後はローリングアップデート等も試したい
まとめ
58

とらのあな抽選会を支えたマイクロサービス_20210611_TechDay#1_1

Recommandé

Recommandé

Contenu connexe

Plus de 虎の穴開発室

Plus de 虎の穴開発室 (20)