とらのあなラボTechConferenceVol.2_Webシステム内製による社内DX

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. ● 名前: 鷺山智之  ● 2021年入社  ● 現在の業務内容  ○ とらのあな通販サイトの機能改修  ○ 新しい社内システムの設計･開発  ● 趣味  ○ アニメを観る  ○ ラジオを聞く  ○ ゲーム実況を観る  自己紹介  2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. ✔ 商品の購入と同じ操作感で補充発注ができる  ✔ 通販システムとの共通化による開発工数＆コスト削減  ✔ 流通オペレーションの統一化、DX化  新しいシステムを作りました  4 ● とらのあな店舗やインショップ(※)からの補充発注を、  とらのあな通販のサイト経由で実施できるシステム。  ※ ｢とらのあな出張所｣として、同人作品を委託販売していただいている店舗   ● 通販サイトで商品を選択し、必要な数量をカートに入れて手続きをすることで各店舗の在庫が補充可能。  ➔以降「補充発注システム」としてご紹介 

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. 補充発注システム - 改修のポイント  10 ● とらのあな通販のシステムの仕組みを一部使用 (共用)。  ➔ ランニング＆オペレーションコスト低減  ● とらのあな直営店だけではなく、各インショップからも  アクセスできるようにする必要がある。  ➔ イントラ内に閉じたシステムにしない  ➔ インショップは今後も増えていくことを想定  ● 補充発注システム自体はマイクロサービスとして独立。  ➔ 通販システムのモノリス化を避ける  ➔ 新しい技術を使って開発したい！  　　　　　 

Slide 11

Slide 11 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. 11 通販システム  流通システム  ・ログイン  ・商品検索  ・カート投入  ・注文確定  一般ユーザー  各ユーザーに配送  システム間構成図 ( 従来)  注文データ  商品データ (商品情報､在庫数)   注文データ  顧客管理システム  顧客データ 

Slide 12

Slide 12 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. 12 通販システム  流通システム  ・ログイン  ・商品検索  ・カート投入  補充発注用ユーザー  各店舗に配送  システム間構成図 (補充発注システム導入後)   注文データ  商品データ (商品情報､在庫数)   注文データ  顧客管理システム  顧客データ  API  補充発注システム  発注ルール (在庫の○割まで発注可)   店舗ごとの発注用テンプレート   New! ・リダイレクト  ・注文確定  新しいユーザー種別を追加   ＋店舗データ

Slide 13

Slide 13 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. インフラ: クラウドサービスの利用  13 ● 外部アクセスに対応＆マネージドな実行基盤  ➔ クラウドサービスを利用したい  ※AWS Direct Connect … AWSとデータセンタ間の専用線接続サービス   ● 今回の要件: 既存システム (オンプレ上) との連携が必要  ● 現状の通販システム(群):  ○ バックエンドはオンプレミス  ○ フロントエンドはAWS  ○ AWSとオンプレ間の通信はAWS Direct Connect※を使用  ➔ 素直にAWSを採用。既存部分の連携もDirect Connectで解決。 

Slide 14

Slide 14 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. AWS Cloud  VPC  Private subnet  Public subnet  補充発注システム - アーキテクチャ   14 Amazon CloudFront  Amazon S3  AWS  Direct Connect  データセンター  (オンプレミス)  Amazon Aurora (Serverless v1)  AWS Fargate (ECS)  Elastic Load Balancing  (ALB)  Internet gateway  サーバー等  VPN gateway  Amazon Cognito  （管理者ユーザーのみ）   補充発注ユーザー  フロントエンド   バックエンド  

Slide 15

Slide 15 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. 利用している主なAWSサービス [とフレームワーク]  15 バックエンド  AWS Fargate (ECS) [Kotlin + Ktor]  フロントエンド  Amazon S3 + CloudFront [Nuxt.js]  データベース  Amazon Aurora Serverless (v1)  ユーザー管理・認証  Amazon Cognito 

Slide 16

Slide 16 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. AWS Fargate (ECS) 採用理由  16 ● サーバーレスでマネージド  ○ 負荷に応じたスケールアウトにも対応    ● コンテナの利点を重視  ○ 開発言語が問われない  ➔ Kotlinで書ける (通販チームの推し言語)  ○ ポータビリティ (ローカルでも同様に実行可)  ○ RDSとの相性⭕ (RDS Proxyいらず)  # AWS App Runner ➔ 当時はVPCに接続できなかった😅

Slide 17

Slide 17 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. Kotlin 採用理由  17 ● 洗練された文法: すっきり気持ちよく書ける。  ● 通販チームで利用実績が多数あり。  ○ 多数の社内ツール  ○ 通販の補助サービス (納品書出力、抽選システム)  ● チームの全員が書ける (入社時の研修課題)。  ● Kotlin+Ktorアプリケーションはコンテナ向き。  ○ 軽くて起動が早い  ■ イメージ100MB以下、数十秒で起動 

Slide 18

Slide 18 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. フロント: S3 Hosting + CloudFront  18 ● 王道の組み合わせ。  ○ S3 Hosting … S3をホスティングサービスとして利用できる  ■ サーバー不要で低コスト。メンテも楽。  ○ CloudFront … CDN  ■ キャッシュ用途よりはSSL化とAWS Shield目的で使用。    ● アプリケーション: Nuxt.js  ○ Vue.js含め社内ツールで実績あり。  ○ 静的サイト生成が可能 (SSG)  ■ ビルド時点でHTMLをあらかじめ生成  ■ 生成物をS3に配置してそのままウェブサイトとして公開できる 

Slide 19

Slide 19 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. DB: Amazon Aurora Serverless  19 ● 普通のAmazon Auroraとの違い:  ✔ オートスケーリングする (設定不要)  ➔ 負荷に応じて自動的に拡大･縮小する  ➔ 自動的に停止･起動する (設定: ｢xx分アクセスがない場合｣)  ✔ 停止している時間は課金されない    ❌ ただし、負荷状況によっては少し割高になることも  ➔ ｢24時間それなりのアクセスが絶え間なく続く｣ようだと不利  ❌ 停止中のものを起動させるのに30秒弱かかる  ● v1とv2 (プレビュー) がある。補充発注システムではv1を使用。 

Slide 20

Slide 20 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. Aurora Serverless 採用理由  20 ● ランニングコストを下げられる  ○ 本番環境  ■ 夜間・早朝は発注業務がないため自動で最小構成になる  (※ ただし、起動に時間がかかるので「停止」まではしていない)   ■ 繁忙期やアクセスが集中する時間帯には自動でスケールアップ    ○ 開発環境  ■ 夜間･早朝･休日や、開発期間外はDBアクセスが発生しない。  ➔ 停止中は課金されないのでコストを節約できる。    ● 今後、負荷が上がってきた時は普通のAuroraに戻せる  ○ エクスポート＋インポートで移行可能 

Slide 21

Slide 21 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. Amazon Cognito  21 ● ユーザー管理や認証まわりの処理をAWSに委任できる  ○ 独自に認証・認可システムを作らずに済む    ● 管理者ユーザー※のアカウント管理や認証に利用  ※ 複数の店舗の発注を管理する、特定の店舗に結びつかない特殊なユーザー。    ● AWSが提供するライブラリ (AWS Amplify) を利用することでログイン・ログアウト、パスワード変更などのコーディングも簡単にできる (用意されている各メソッドを呼ぶだけ)。    ● 注意点: エラーメッセージを英語から日本語に変換する必要があります... 😅 

Slide 22

Slide 22 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. 新システム稼働状況  22 ✔ 安定稼働中  ➔ リリースして5ヶ月、大きなトラブルや障害なし    ✔ 実際の発注業務で大いに活用中  ➔ これまでに5,500件以上の注文を処理    ✔ 改修が容易。現在も機能をどんどん追加中  ➔ 独立した小さいシステムなので改修の影響が少ない    ✔ インショップ店舗が増えても対応可能  ➔ アカウントを追加するだけでOK 

Slide 23

Slide 23 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. まとめ  23 ● マイクロサービスでの開発が上手くはまった  ✔ 既存システムから独立して改修ができる  ✔ 新しい技術を試せる  ● コスパの良い、安定したシステムが作れた  ✔ 適切なアーキテクチャ設計と技術選定  ● とらラボはエンジニアに裁量を持たせてくれる 

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Copyright (C) 2020 Toranoana Inc. All Rights Reserved. Copyright © 2022 Toranoana Inc. All Rights Reserved. CI/CD  26   バックエンド  フロントエンド  ビルド  フロー  1. GitHubにpush➔CodeBuildに通知   2. CodeBuildでビルド&デプロイ               3. CodePipelineでECSサービスを更新   ● imagedefinitions.json の内容で更新  1. GitHubにpush➔CodeBuildに通知   2. CodeBuildでビルド&デプロイ             ● generate の実態は nuxt generate  ● --delete で同期元に存在しないファイルを同期先から削除できる  ● CloudFrontキャッシュ無効化で即時反映   自動  テスト  Kotlin Test  Jest  - ./gradlew build - docker build -t … - docker push … - echo "…" > imagedefinition.json - zip imagedefinitions.zip imagedefinitions.json - npm run generate - aws s3 sync dist s3://… --delete - aws cloudfront create-invalidation --distribution-id … --paths '/*'