「HOT PEPPER Beauty」美容クリニックをリリースしました
岩永 卓也
HOT PEPPER Beauty EngineerLead 兼美容クリニック開発統括の岩永です。 先日 HOT PEPPER Beauty に新しく美容クリニックのカウンセリング 予約ができるサービス をリリースしました。 本記事では HOT PEPPER Beauty の美容クリニック（以下 美容クリニック）のアーキテクチャ & 技術スタック、開発体制など 美容クリニックのプロダクト開発の概要を紹介していきます。
アーキテクチャ & 技術スタック
アプリケーションのアーキテクチャ
美容クリニックでは Web アプリケーションと Batch アプリケーションがありますが、Web アプリケーションは
- フロントアプリケーション、API アプリケーションの分離(以下 フロント/API 分離)
- 取り扱う業務ドメインごとの API 分離(以下 API ドメイン分離)
を行っています。フロントアプリケーションは全部で 4 つのアプリケーションから構成されていますが、そのうち予約管理を行うシステムを例にすると、以下のような構成になっています。
まず、フロント/API 分離についてですが、フロントアプリケーションと API アプリケーションで以下のような責務分担で分離しています。
フロントアプリケーションの責務
- 正しい情報を画面に表示させること(必要に応じてデータ加工など)
- 画面遷移に関わる制御処理
- 認証
- ロールや所属組織による権限管理・処理
API の責務
- 業務ロジック
- データの永続化
これにより、画面に関わる関心事と業務に関わる関心事を分離して複雑性を減らすという効果と、画面周りの修正頻度とビジネスロジックの修正頻度の差をうまく吸収してリリーススコープの限定化などが可能になりました。
次に API のドメイン分離についてですが、以下のように業務ドメインごとに分離しています。
- 営業の契約受注、掲載原稿の入稿に関する業務
- 予約精算に関する業務
- 会員に関する業務
これにより業務に関わる関心事をできるだけ凝集度高く実装し、相互の依存を最小化したことで分業が可能になり、加えて業務ごとの負荷に応じて柔軟にスケールアップ・スケールアウトが可能になりました。 とくに今回のサービスではとくに美容クリニックは幅広い業務をカバーする必要があり、システム規模が大きいため、開発メンバーそれぞれがすべての業務や技術スタック、アーキテクチャを理解するというのは難しく、上記のようにシステムを分けて開発/運用していくことは大変重要な意味がありました。
技術スタック
アプリケーションは基本 AWS 上の ECS on Fargate に構築していて、Web、Batch ともに Java11 + Spring Boot v2 で実装されています。 主な技術としては下の表のようなものを使っています。
| 役割 | 技術スタック |
|---|---|
| データの永続化 | Amazon Aurora MySQL |
| セッションストレージ、キャッシュストレージ | ElastiCache |
| 検索エンジン | Elasticsearch + Logstash |
| ワークフローエンジン | Digdag |
| CDN | Akamai, CloudFront |
| 画像管理 | Akamai Image Manager |
| ログアグリゲーション | fluentd |
| モニタリング | Datadog |
| JavaScript のエラーモニタリング | Sentry |
| データ分析、ログ解析 | BigQuery |
| 分散トレーシング | X-Ray |
| 高負荷試験ツール | Gatling |
| 画像処理などちょっとした非同期処理 | Lambda |
| CI | CodeBuild, Drone |
開発体制
サービス立ち上げ時は 一時 50 名規模での開発を行っていましたが、リリースを終えた今エンジニアは 15 名ほどでの体制で開発を行っており、機能開発をする機能開発チーム(12 名前後)とそれを支える SRE チーム(3 名前後)の 2 チームから構成されています。
機能開発チーム
- 機能開発案件の推進・実行
- 本番稼動システムのモニタリング
などをミッションにもつチームです。
機能開発については、月 1 回企画ディレクターと開発計画の見直しを行い、案件優先順位に従って実施しており、案件規模によって 1 案件 1〜4 名ほどのチームを組んで開発し、月 1 回のペースでリリースを行っています。サービス立ち上げ時はエンジニアそれぞれが限定された業務ドメインや技術スタックを担当することが多かったですが、今は少しずつローテーションしながら開発しており、日々学習しながら開発を進めています。
システムモニタリングについては、Datadog で用意した各システムのメトリクスダッシュボードを見ながらの能動的なモニタリングと、Datadog や CloudWatch からのエラー通知などをトリガーにした受動的な対応などによって、サービス稼働を支えています。
SRE チーム
- DX (Developer Experience) の改善
- システム可用性の維持と改善
- 機能開発チームの技術支援
などをミッションにもつチームです。
DX 改善では CI/CD の導入と改善、開発環境やテスト環境のインフラ整備と運用/改善などをおこなっており、開発や運用の効率化/自動化を実践し、開発部隊を支えています。
システム可用性の維持/改善については、Datadog などを用いてインフラメトリクスのモニタリングや、SLI/SLO のモニタリングを行い、障害点の解消や性能改善の施策検討・実施など行っています。
技術支援については、機能開発案件でミドルウェアを新規に導入する、もしくは既存のミドルウェアで新しい feature を利用する、といった際の事前検証や導入時の技術支援を行っています。
まとめ
本記事では 美容クリニックの開発の概要について紹介してきましたが、より詳細な内容についてはトピックごとに順次テックブログ上にポストしていきたいと思っておりますのでぜひそちらもよろしくお願いします。
美容クリニックは先月リリースしたばかりですので、日々サービスの KPI の数字に一喜一憂しながら、サービス改善をすべくアジリティ高く機能開発を実践しています。サービス成長を肌で感じながら、様々な技術チャレンジやドメイン設計に関われる環境があります。興味がある方がいらっしゃいましたら、ぜひ採用ページを御覧ください。