シングルテナントの受難

Transcript

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