シングルテナントの受難SaaS on AWS 2022 LT枠
View Slide
PRESENTATIONAGENDA01 私とhacomonoについて02 弊社サービスの特性03 課題と解決策04 これからについて
section01 私とhacomonoについて
4section 01: 私とhacomonoについて株式会社 hacomono 大西 時雨 / Shigure OnishiSREチーム マネージャー 香川県の離島からフルリモートで勤務2021年8月にhacomonoに入社好きなAWSのサービスはS3
55代 表： 蓮田 健一設 立： 2013年7月 (現在10期目)住 所： 東京都渋谷区神宮前2丁目34番17号 住友不動産原宿ビル5Fメンバー： 120名フィットネスクラブなど、月謝制店舗向け会員管理・予約・決済システムhacomono開発・販売株式会社hacomono
for Company6これまでの歩みHistory暗闇フィットネスジムの予約・キャッシュレス決済システムを開発2016 2022これまでの事例から、店舗予約や事前オーダーシステムに関する相談を多数頂くようになる2017これまでの店舗運営ビジネスのノウハウを生かした会員管理・予約・決済システム、hacomono 正式リリース！1年で導入店舗数が 100店舗を超える2019ALL STAR SAAS FUND を引受先とした1億円の資金調達を実施。2020ALL STAR SAAS FUND を引受先とした シリーズAラウンドにおける5億円の資金調達を実施。社名を株式会社hacomonoへ変更(旧社名: 株式会社まちいろ )2021シニフィアン株式会社及びみずほキャピタル株式会社共同運営「THE FUND」を新規リード投資家として、Coral Capital、ALL STAR SAAS FUNDを引受先としたシリーズBラウンドにおける、総額20億円の資金調達を実施。
7section 01: 私とhacomonoについて - これまでの歩み受託開発
8section 01: 私とhacomonoについて - これまでの歩みうちも導入したい※ ソースコードは受託時から書き直してます
9section 01: 私とhacomonoについて - これまでの歩みお宅のシステムいいね、うちもやりたい
10section 01: 私とhacomonoについて - これまでの歩み以下略
11section 01: 私とhacomonoについて - これまでの歩み恐ろしいことに、、、 (VPCレベルのサイロモデル)
12section 01: 私とhacomonoについて - これまでの歩み数千台数千台EC2 RDS私の人生初の経験🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉
section02 弊社サービスの特性
14section 02: 弊社サービスの特性スケジュール公開フィットネスクラブのレッスン予約は熱いオンライン化する前は店舗に行列ができるような状態我々は慣習をオンラインに持っていった
15section 02: 弊社サービスの特性場所指定システム
16section 02: 弊社サービスの特性スケジュール公開
17section 02: 弊社サービスの特性スケジュール公開
18section 02: 弊社サービスの特性スケジュール公開事前に顧客から公開時間を聞いてスケジュールセット場合によってはメンテナンスを入れて深夜にDB強化(Aurora Serverless v2も絶賛検証中)
19section 02: 弊社サービスの特性Terraform Modules1. AutoScaling GroupのScheduled actionを活用a. 簡単にスケジュール登録できるようにModule化2. RDSも指定時刻にmodify-db-instanceを実行するModule作成a. Maintenance Windowだと一週間先が限界
20section 02: 弊社サービスの特性Terraform ModulesRDSの更新はTerraform Registryに公開中https://registry.terraform.io/modules/hacomono/modify-db-schedule/aws/latest
21section 02: 弊社サービスの特性 - 私のお気持ちビジネスは制約があるから面白い、制約を楽しもう01低コストでビジネスを回す楽しさコストを意識しなくていいなら最強インスタンスを大量に並べるだろう。ただ、それだとビジネスは成り立たないし、実績という感触が薄い。02改善していく楽しさ03難しい問題を解けた時の快感敵が強ければ強いほどワクワクする。新規機能の開発をして、新たに収益を上げるシステムを作ることも楽しい。だが、日々の問題が少しずつ改善していく状態を見るのも楽しい。
課題山盛りは大好物22💖2.2
section03課題と解決策4）リソースのムダ使い2）メモリ管理がシビア3）毎週AWSの上限緩和チェック1）EC2のSLAの壁
section03課題と解決策1）EC2のSLAの壁
25section 03: 課題と解決策 - EC2のSLAの壁EC2単体のSLAは99.5%2021年時はSLAが90%だった出典元: https://aws.amazon.com/compute/sla
26section 03: 課題と解決策 - EC2のSLAの壁ALBのコストが 4,000円/月 程度その分サービス利用料を安くしてあげたいSMBの顧客だし冗長化はいらないか
27section 03: 課題と解決策 - EC2のSLAの壁サーバダウン発生するとIPが、、、Elastic IPで固定しよう
28section 03: 課題と解決策 - EC2のSLAの壁Elastic IPが大量に必要になってくる一時期、弊社で2,000個Elastic IP持ってました 🙇
29section 03: 課題と解決策 - EC2のSLAの壁ある日のことAWS < これ以上は無理 (意訳)私 < そうですよねー
30section 03: 課題と解決策 - EC2のSLAの壁Dynamic DNSの実装1. AutoScaling Groupで台数を1台にする2. EC2起動時に自然に割り振られたIPを拾ってくる3. Route53の書き換え
31section 03: 課題と解決策 - EC2のSLAの壁EC2のSLAの壁TRY改善ポイントAutoScaling Group対応顧客のDNSを自社で管理RTN得られたものElatic IPを抱える必要がなくなったAWSの上限に怯える必要がなくなった未来のアーキ変更でも対応しやすい※ 現在はElastic IP枯渇してないので使っていないトリッキーなことはあまりしたくないので、普通に IPを固定して運用している
32section 03: 課題と解決策 - EC2のSLAの壁学び: 小規模でもロードバランサーあった方がいい1. アクセスログを残す仕組みを自前で導入しなければいけない2. Dynamic DNSを生み出さなければいけないほど困った3. EC2のインスタンスのリタイア時も面倒4. リクエスト数とかメトリクス見れるのありがたいとはいえ、数千台分のALBを立てると4,000円 * 数千台 = 数百万円
section03課題と解決策2）メモリ管理がシビア
34section 03: 課題と解決策 - メモリ管理がシビア通常運用時: メモリを90%ぐらい使用1. FluentdとかCloudWatch Logsに記録残したいAgentを入れたりする？それってメモリは足りる？2. 少し重めの新機能追加したらメモリ枯渇機能開発時にメモリを意識して開発する必要がある
35section 03: 課題と解決策 - メモリ管理がシビアインスタンスタイプ上げれば？数千台のインスタンスのタイプを1ランク上げると数百万レベルロードバランサーの話にも通ずるが全顧客に反映すると大変なことにメモリは札束
36section 03: 課題と解決策 - メモリ管理がシビアフロント側にログ収集の仕組みを設けるフロント側にWebビーコン型のログ収集機能を作る1. ページを読み込んだタイミングでCloudFrontにアクセス2. CloudFrontのログはS3に残す
37section 03: 課題と解決策 - メモリ管理がシビアフロント側にログ収集の仕組みを設けるCloudFrontなのでサーバ管理ほぼ不要で安定稼働アクセスしているページやユーザーの情報などをQuery Parameterに付与数千テナントあるがこのCloudFrontは一つ、横断で見れる分析基盤
38section 03: 課題と解決策 - メモリ管理がシビア得られたもの: 分析基盤ができた※ ブラウザでやってる以上、完璧なアクセスログではないアクセスの傾向がわかるレベルのもの
39section 03: 課題と解決策 - メモリ管理がシビアメモリ管理がシビアTRY改善ポイントフロント側を工夫する管理コストの低いEndpoint作成RTN得られたものアクセス傾向がわかったSPA実装でもアクセスページがわかったテナント横断で分析S3に持ってこれたので後はなんとでもなる
section03課題と解決策3）毎週AWSの上限緩和チェック
41section 03: 課題と解決策 - 毎週AWSの上限緩和チェック全てのリソースにおいて数千の確保が必要VPC、Elastic IP、S3、EC2、RDSなどなどが引っかかるしかしTrusted Advisorで検知できるものは11リソースのみ参考: https://www.amazonaws.cn/en/support/trustedadvisor/faq/毎週のように行われる上限確認市場規模や価格設定を考慮してテナント分離モデルは考えた方がいい
42section 03: 課題と解決策 - 毎週AWSの上限緩和チェック良きPackageに出会えたpip install awslimitchecker参考: https://github.com/jantman/awslimitchecker27サービスに対応している(リソース数は不明)Kinesis Data Firehose、Redshift、Elastic Beanstalkなども対応している
43section 03: 課題と解決策 - 毎週AWSの上限緩和チェック毎週AWSの上限緩和チェックTRY改善ポイントawslimitcheckerの導入結果を社内ツールに通知RTN得られたもの毎週の確認がなくなった
section03課題と解決策4）リソースのムダ使い
45section 03: 課題と解決策 - リソースのムダ使い各テナントのCPU使用率各テナントでピークタイムが違う、3台分のパワーを使えるはずが、、、
46section 03: 課題と解決策 - リソースのムダ使いマルチテナント化 (ティアベース)TRY改善ポイントEC2の管理は避けたいので Fargate採用顧客を識別・担保する仕組みの構築RDSも1インスタンスで複数の顧客対応可能RTN得られたもの管理コスト激減(予定)メモリ不足に悩まなくて良いAWS service quotas気にしなくて良い
section04 これからについて
48スタートラインに立つことができるCloud Design Patternな戦略ができる１ 32AWS費用大幅削減人的リソース大幅削減開発効率大幅改善これまでの状態でもしっかり契約を取ることができている。ここからさらに開発にドライブをかける ことができる。この過酷な状況を耐えてきた猛者が揃っているので今後もきっとやっていける。伸びしろしかない
49スタートラインに向けてあと少し大量の顧客のテナント移行作業があるデータベースの移行作業はとても大変それを数千環境頑張らなければいけない顧客によっては契約書レベルで修正対応
50新たな問題に立ち向かうBotユーザーに向き合うシステムの仕様上取り合いが必ず発生する取り合いが発生するシステムにはBotが生まれる便利な仕組みは良いとは思うがITリテラシーが低い人が損する仕組みは作りたくはない
51新たな問題に立ち向かうBotユーザーに向き合う対策案1) AWS WAF Bot Control2) Amazon Fraud Detector3) Amazon SageMaker4) reCAPTCHA v3
52Copyright Machiiro Inc. All Rights Reserved.私たちはフィットネス業界の新しいプラットフォームを構築していきます。一人では決して達成できない大きな目標を成し遂げるために、心強い仲間を募集しています。Join us!こんな仲間を募集しています● 「私」ではなく「お客様」を主語に業務を捉えられる方● 現状維持ではなく、会社・自己の成長、カイゼン意欲のある方● プロ意識・責任感を持って仕事に取り組める方
Missionご清聴、ありがとうございました
hacomono
masashi_sutou
pauloxnet
hariby
oracle4engineer
konboi
dena_tech
tsubakimoto_s
renjikari
datarian
ywada526
takakuni
ufuk
yeseniaperezcruz
zenorocha
danielanewman
trallard
thekraken
mojombo
hannesfritz
chriscoyier
samanthasiow
3n
destraynor