Upgrade to Pro — share decks privately, control downloads, hide ads and more …

シングルテナントの受難

 シングルテナントの受難

hacomono Inc.

November 29, 2022
Tweet

More Decks by hacomono Inc.

Other Decks in Technology

Transcript

  1. シングルテナントの受難
    SaaS on AWS 2022 LT枠

    View full-size slide

  2. PRESENTATION
    AGENDA
    01 私とhacomonoについて
    02 弊社サービスの特性
    03 課題と解決策
    04 これからについて

    View full-size slide

  3. section
    01 私とhacomonoについて

    View full-size slide

  4. 4
    section 01: 私とhacomonoについて
    株式会社 hacomono

    大西 時雨 / Shigure Onishi
    SREチーム マネージャー

    香川県の離島からフルリモートで勤務
    2021年8月にhacomonoに入社
    好きなAWSのサービスはS3

    View full-size slide

  5. 5
    5
    代 表: 蓮田 健一
    設 立: 2013年7月 (現在10期目)
    住 所: 東京都渋谷区神宮前
    2丁目34番17号 住友不動産原宿ビル
    5F
    メンバー: 120名
    フィットネスクラブなど、月謝制店舗向け会員管理・予約・決済システム
    hacomono開発・販売
    株式会社hacomono

    View full-size slide

  6. for Company
    6
    これまでの歩み
    History
    暗闇フィットネスジムの
    予約・キャッシュレス決済システムを開発
    2016 2022
    これまでの事例から、
    店舗予約や事前オーダーシステムに関
    する相談を多数頂くようになる
    2017
    これまでの店舗運営ビジネスのノウハウを生
    かした会員管理・予約・決済システム、
    hacomono 正式リリース!
    1年で導入店舗数が 100店舗を超える
    2019
    ALL STAR SAAS FUND を引受先とした
    1億円の資金調達を実施

    2020
    ALL STAR SAAS FUND を引受先とした シ
    リーズAラウンドにおける
    5億円の資金調達を実施

    社名を株式会社hacomonoへ変更
    (旧社名: 株式会社まちいろ )
    2021
    シニフィアン株式会社及びみずほキャピタル株式会社共
    同運営「THE FUND」を新規リード投資家として、
    Coral Capital、ALL STAR SAAS FUNDを引受先とした
    シリーズBラウンドにおける、
    総額20億円の資金調達を実施。

    View full-size slide

  7. 7
    section 01: 私とhacomonoについて - これまでの歩み
    受託開発

    View full-size slide

  8. 8
    section 01: 私とhacomonoについて - これまでの歩み
    うちも導入したい
    ※ ソースコードは受託時から書き直してます

    View full-size slide

  9. 9
    section 01: 私とhacomonoについて - これまでの歩み
    お宅のシステムいいね、うちもやりたい

    View full-size slide

  10. 10
    section 01: 私とhacomonoについて - これまでの歩み
    以下略

    View full-size slide

  11. 11
    section 01: 私とhacomonoについて - これまでの歩み
    恐ろしいことに、、、 (VPCレベルのサイロモデル)

    View full-size slide

  12. 12
    section 01: 私とhacomonoについて - これまでの歩み
    数千台
    数千台
    EC2 RDS
    私の人生初の経験
    🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉

    View full-size slide

  13. section
    02 弊社サービスの特性

    View full-size slide

  14. 14
    section 02: 弊社サービスの特性
    スケジュール公開
    フィットネスクラブのレッスン予約は熱い
    オンライン化する前は店舗に行列ができるような状態
    我々は慣習をオンラインに持っていった

    View full-size slide

  15. 15
    section 02: 弊社サービスの特性
    場所指定システム

    View full-size slide

  16. 16
    section 02: 弊社サービスの特性
    スケジュール公開

    View full-size slide

  17. 17
    section 02: 弊社サービスの特性
    スケジュール公開

    View full-size slide

  18. 18
    section 02: 弊社サービスの特性
    スケジュール公開
    事前に顧客から公開時間を聞いてスケジュールセット
    場合によってはメンテナンスを入れて深夜にDB強化
    (Aurora Serverless v2も絶賛検証中)

    View full-size slide

  19. 19
    section 02: 弊社サービスの特性
    Terraform Modules
    1. AutoScaling GroupのScheduled actionを活用
    a. 簡単にスケジュール登録できるようにModule化
    2. RDSも指定時刻にmodify-db-instanceを実行するModule作成
    a. Maintenance Windowだと一週間先が限界

    View full-size slide

  20. 20
    section 02: 弊社サービスの特性
    Terraform Modules
    RDSの更新はTerraform Registryに公開中
    https://registry.terraform.io/modules/hacomono/modify-db-schedule/aws/latest

    View full-size slide

  21. 21
    section 02: 弊社サービスの特性 - 私のお気持ち
    ビジネスは制約があるから面白い、制約を楽しもう
    01
    低コストでビジネスを回す楽しさ
    コストを意識しなくていいなら最強インスタンスを大量に並べるだろう。ただ、それ
    だとビジネスは成り立たないし、実績という感触が薄い。
    02
    改善していく楽しさ
    03
    難しい問題を解けた時の快感
    敵が強ければ強いほどワクワクする。
    新規機能の開発をして、新たに収益を上げるシステムを作ることも楽しい。だが、
    日々の問題が少しずつ改善していく状態を見るのも楽しい。

    View full-size slide

  22. 課題山盛りは大好物
    22
    💖
    2.2

    View full-size slide

  23. section
    03
    課題と解決策
    4)リソースのムダ使い
    2)メモリ管理がシビア
    3)毎週AWSの上限緩和チェック
    1)EC2のSLAの壁

    View full-size slide

  24. section
    03
    課題と解決策
    1)EC2のSLAの壁

    View full-size slide

  25. 25
    section 03: 課題と解決策 - EC2のSLAの壁
    EC2単体のSLAは99.5%
    2021年時はSLAが90%だった
    出典元: https://aws.amazon.com/compute/sla

    View full-size slide

  26. 26
    section 03: 課題と解決策 - EC2のSLAの壁
    ALBのコストが 4,000円/月 程度
    その分サービス利用料を安くしてあげたい
    SMBの顧客だし冗長化はいらないか

    View full-size slide

  27. 27
    section 03: 課題と解決策 - EC2のSLAの壁
    サーバダウン発生するとIPが、、、
    Elastic IPで固定しよう

    View full-size slide

  28. 28
    section 03: 課題と解決策 - EC2のSLAの壁
    Elastic IPが大量に必要になってくる
    一時期、弊社で2,000個Elastic IP持ってました 🙇

    View full-size slide

  29. 29
    section 03: 課題と解決策 - EC2のSLAの壁
    ある日のこと
    AWS < これ以上は無理 (意訳)
    私 < そうですよねー

    View full-size slide

  30. 30
    section 03: 課題と解決策 - EC2のSLAの壁
    Dynamic DNSの実装
    1. AutoScaling Groupで台数を1台にする
    2. EC2起動時に自然に割り振られたIPを拾ってくる
    3. Route53の書き換え

    View full-size slide

  31. 31
    section 03: 課題と解決策 - EC2のSLAの壁
    EC2のSLAの壁
    TRY
    改善ポイント
    AutoScaling Group対応
    顧客のDNSを自社で管理
    RTN
    得られたもの
    Elatic IPを抱える必要がなくなった
    AWSの上限に怯える必要がなくなった
    未来のアーキ変更でも対応しやすい
    ※ 現在はElastic IP枯渇してないので使っていない
    トリッキーなことはあまりしたくないので、普通に IPを固定して運用している

    View full-size slide

  32. 32
    section 03: 課題と解決策 - EC2のSLAの壁
    学び: 小規模でもロードバランサーあった方がいい
    1. アクセスログを残す仕組みを自前で導入しなければいけない
    2. Dynamic DNSを生み出さなければいけないほど困った
    3. EC2のインスタンスのリタイア時も面倒
    4. リクエスト数とかメトリクス見れるのありがたい
    とはいえ、数千台分のALBを立てると4,000円 * 数千台 = 数百万円

    View full-size slide

  33. section
    03
    課題と解決策
    2)メモリ管理がシビア

    View full-size slide

  34. 34
    section 03: 課題と解決策 - メモリ管理がシビア
    通常運用時: メモリを90%ぐらい使用
    1. FluentdとかCloudWatch Logsに記録残したい
    Agentを入れたりする?それってメモリは足りる?
    2. 少し重めの新機能追加したらメモリ枯渇
    機能開発時にメモリを意識して開発する必要がある

    View full-size slide

  35. 35
    section 03: 課題と解決策 - メモリ管理がシビア
    インスタンスタイプ上げれば?
    数千台のインスタンスのタイプを1ランク上げると数百万レベル
    ロードバランサーの話にも通ずるが全顧客に反映すると大変なことに
    メモリは札束

    View full-size slide

  36. 36
    section 03: 課題と解決策 - メモリ管理がシビア
    フロント側にログ収集の仕組みを設ける
    フロント側にWebビーコン型のログ収集機能を作る
    1. ページを読み込んだタイミングでCloudFrontにアクセス
    2. CloudFrontのログはS3に残す

    View full-size slide

  37. 37
    section 03: 課題と解決策 - メモリ管理がシビア
    フロント側にログ収集の仕組みを設ける
    CloudFrontなのでサーバ管理ほぼ不要で安定稼働
    アクセスしているページやユーザーの情報などをQuery Parameterに付与
    数千テナントあるがこのCloudFrontは一つ、横断で見れる分析基盤

    View full-size slide

  38. 38
    section 03: 課題と解決策 - メモリ管理がシビア
    得られたもの: 分析基盤ができた
    ※ ブラウザでやってる以上、完璧なアクセスログではない
    アクセスの傾向がわかるレベルのもの

    View full-size slide

  39. 39
    section 03: 課題と解決策 - メモリ管理がシビア
    メモリ管理がシビア
    TRY
    改善ポイント
    フロント側を工夫する
    管理コストの低いEndpoint作成
    RTN
    得られたもの
    アクセス傾向がわかった
    SPA実装でもアクセスページがわかった
    テナント横断で分析
    S3に持ってこれたので後はなんとでもなる

    View full-size slide

  40. section
    03
    課題と解決策
    3)毎週AWSの上限緩和チェック

    View full-size slide

  41. 41
    section 03: 課題と解決策 - 毎週AWSの上限緩和チェック
    全てのリソースにおいて数千の確保が必要
    VPC、Elastic IP、S3、EC2、RDSなどなどが引っかかる
    しかしTrusted Advisorで検知できるものは11リソースのみ
    参考: https://www.amazonaws.cn/en/support/trustedadvisor/faq/
    毎週のように行われる上限確認
    市場規模や価格設定を考慮してテナント分離モデルは考えた方がいい

    View full-size slide

  42. 42
    section 03: 課題と解決策 - 毎週AWSの上限緩和チェック
    良きPackageに出会えた
    pip install awslimitchecker
    参考: https://github.com/jantman/awslimitchecker
    27サービスに対応している(リソース数は不明)
    Kinesis Data Firehose、Redshift、Elastic Beanstalkなども対応している

    View full-size slide

  43. 43
    section 03: 課題と解決策 - 毎週AWSの上限緩和チェック
    毎週AWSの上限緩和チェック
    TRY
    改善ポイント
    awslimitcheckerの導入
    結果を社内ツールに通知
    RTN
    得られたもの
    毎週の確認がなくなった

    View full-size slide

  44. section
    03
    課題と解決策
    4)リソースのムダ使い

    View full-size slide

  45. 45
    section 03: 課題と解決策 - リソースのムダ使い
    各テナントのCPU使用率
    各テナントでピークタイムが違う、3台分のパワーを使えるはずが、、、

    View full-size slide

  46. 46
    section 03: 課題と解決策 - リソースのムダ使い
    マルチテナント化 (ティアベース)
    TRY
    改善ポイント
    EC2の管理は避けたいので Fargate採用
    顧客を識別・担保する仕組みの構築
    RDSも1インスタンスで複数の顧客対応可能
    RTN
    得られたもの
    管理コスト激減(予定)
    メモリ不足に悩まなくて良い
    AWS service quotas気にしなくて良い

    View full-size slide

  47. section
    04 これからについて

    View full-size slide

  48. 48
    スタートラインに立つことができる
    Cloud Design Patternな戦略ができる
    1 3
    2
    AWS費用
    大幅削減
    人的リソース
    大幅削減
    開発効率
    大幅改善
    これまでの状態でもしっかり契約を取ることができている。
    ここからさらに開発にドライブをかける ことができる。
    この過酷な状況を耐えてきた猛者が揃っているので今後もきっとやっていける。
    伸びしろしかない

    View full-size slide

  49. 49
    スタートラインに向けてあと少し
    大量の顧客のテナント移行作業がある
    データベースの移行作業はとても大変
    それを数千環境頑張らなければいけない
    顧客によっては契約書レベルで修正対応

    View full-size slide

  50. 50
    新たな問題に立ち向かう
    Botユーザーに向き合う
    システムの仕様上取り合いが必ず発生する
    取り合いが発生するシステムにはBotが生まれる
    便利な仕組みは良いとは思うが
    ITリテラシーが低い人が損する仕組みは作りたくはない

    View full-size slide

  51. 51
    新たな問題に立ち向かう
    Botユーザーに向き合う対策案
    1) AWS WAF Bot Control
    2) Amazon Fraud Detector
    3) Amazon SageMaker
    4) reCAPTCHA v3

    View full-size slide

  52. 52
    Copyright Machiiro Inc. All Rights Reserved.
    私たちはフィットネス業界の新しいプラットフォームを構築していきます。
    一人では決して達成できない大きな目標を成し遂げるために、心強い仲間を募集しています。
    Join us!
    こんな仲間を募集しています
    ● 「私」ではなく「お客様」を主語に業務を捉えられる方
    ● 現状維持ではなく、会社・自己の成長、カイゼン意欲のある方
    ● プロ意識・責任感を持って仕事に取り組める方

    View full-size slide

  53. Mission
    ご清聴、ありがとうございました

    View full-size slide