mk

# プロジェクト名：美容サロン向け予約・管理プラットフォーム「SalonCore」開発 ## 期間 2025年〜現在 ## 担当範囲 設計 / バックエンド開発 / フロントエンド開発 / インフラ構築 / SEO・運用設計 ## プロジェクト概要 個人経営や小規模サロン向けに、予約・顧客管理をシンプルに行えるSaaS「SalonCore」を開発・運用。 HP：https://saloncore.jp 通っている美容院のオーナーからの「予約管理コストが高い」という相談を基に、要件をヒアリングし設計、実装からリリース、運用まで一気通貫で対応。 徹底したコスト削減と安定した運用のバランスが肝 ## 技術構成 * フロントエンド：Next.js（React）、TypeScript、Tailwind CSS * バックエンド：Node.js（Express / Knex.js）、TypeScript * データベース：PostgreSQL（v17） * インフラ：Docker / Nginx / Cloudflare / Sakura VPS（Ubuntu 24.04） * ストレージ：MinIO（S3互換）、AWS S3 ## 担当業務・実績 * クライアントからのヒアリングを通した要件定義の実施 * フロント〜バックエンド〜DBをフルスタックで設計・構築 * Docker Composeを用いたマルチコンテナ環境の設計・本番デプロイ * セッション認証・CSRF対策・TLS構成などセキュリティ実装 * Next.jsによるSEO最適化（構造化データ・動的メタタグ・高速化対応）により、月間CTR20%を達成 * Cloudflare＋Let’s EncryptによるSSL・WAF構成を導入 * MinIOを利用したS3互換ストレージ構築（画像・ファイルアップロード対応） * AWS SES、S3、IAM等のAWSサービスの導入 ## 成果・工夫点 ### ①認証周りの技術選定 ■課題 　業務用途のため、営業時間中はログイン状態を維持する必要があったが、JWTトークンベースでは仕組みが複雑になる ■対応 　セッションベースの認証に移行し、認証状態をバックエンドとＤＢでのみ管理するように変更 ■成果 　業務要件を満たす実装を実現した。 　フロントエンドにsession_idを正しく保持させる以外は認証の状態をバックエンドとＤＢでのみ保持、管理できるようになったため、思想が単純化し実装ミスを未然に防げた。 ### ②セキュリティと運用監視 ■課題 CVE-2025-55182 公表直後に遠隔でのコード実行を試行するリクエストが大量に投げられるインシデントが発生 幸い本番環境のコンテナは、「read-only」で実行していたため、実際のコード実行はなかったが、 　(1) コード実行の試行によるセキュリティリスク 　(2) 大量のリクエストによるコンテナダウンによるサービス停止 などの問題が発生。 ■対応 (1) コード実行の試行によるセキュリティリスク 迅速にReactのバージョンを脆弱性の無いバージョンへアップデートを実施 さらにCloudflareのWAFを導入し、将来的な脆弱性へ備える (2) 大量のリクエストによるコンテナダウンによるサービス停止 当時、MVPに毛が生えた程度のサービスだったため限られたサーバーリソースで運営していた そのため、大量のリクエストによりリソースが枯渇しコンテナが落ちて一定時間サービス停止する事態が数回発生 対応としてサービス停止を瞬時に把握、復旧する仕組みを構築 　【外形監視】 　・フロントエンド、バックエンドにhealthcheckAPIを実装 　・外形監視でhealthcheckAPIのエンドポイントを1分毎に叩き、レスポンスが200以外であればアラート 　【内部監視】 　・autohealコンテナを設置し、フロントエンド、バックエンド、WEBサーバー、dockerネットワークそれぞれのhealthcheckAPIエンドポイントを叩き、レスポンスを確認することによる内部監視を実装 　・レスポンスが200以外であれば、autohealによる自動再起動を実行 ■成果 上記対応後は、外部から悪意のあるリクエストがサーバーに届くことはなく、過去半年の意図せぬサービス停止時間は3分以内に抑制 安定したサービス提供を実現 ### ③dokcer採用 ■課題 　コスト（+パフォーマンス）最適化のため、将来的なサービス単位での環境移行が見込まれる。 　そのため、サービス単位で疎結合なアーキテクチャにする必要があった。 ■対応 　docker、docker-composeを導入し、サービス単位(フロントエンド、バックエンド、DB、etc...)でコンテナを分割 　Nginxをリバースプロキシとして導入し、ドメインへのリクエストを各コンテ ナに適切に振り分けるよう構成 ■成果 　docker環境での柔軟で安定した運用を実現 　DBをAWS RDSへの環境移行テストをスムーズに完了（本番環境では運用上の都合で実施せず） ### ④S3互換サービス採用 ■課題 　開発環境への費用発生は排除する必要があったが、開発段階でS3を利用すると費用が発生する問題があった ■対応 　S3互換のMinIOを採用 ■成果 　開発工程での費用発生を抑制 　副次的な効果として、開発環境をローカルに収めたことによって、ネット環境がない場所でも開発が可能になった 　S3互換の為、本番環境デプロイ時に環境変数を変えるだけでストレージの向き先をMinIOからS3に変更出来たため、工数を圧縮を実現 ### ⑤インフラ費用の削減 ■課題 資金が限られておりインフラに支払える金額が限られていた ■対応 サーバーをさくらのVPS1台構成とし環境構築やCI/CDを自前で構築することによってコストを削減 さらに、メール配信はAWS SES、ストレージはAWS S3、DNSとWAFはCloudflareと無料枠や従量課金を効果的に適用させることでコストを削減 ■成果 インフラ運用費用をランチ1回分程度に抑えた。