はじめに
株式会社CAMの川島です。
今回はCAM内にて展開している、社内共通基盤サービスについて紹介していきます
CAMの共通基盤
基盤化をした目的
課題
CAMでは、占い事業、アーティストファンビジネスを中心に、BtoCのプロダクト開発・運用を行っています。
複数サービスを展開をする中で、認証、決済、メール送信などサービスによって差ができにくい部分の開発の効率化が課題になりました。
まず共通基盤として開発をする以前では、ソースコードレベルでの共通処理の管理をはじめました。
結果としてソースコードの共通化により、新規立ち上げの際に都度都度同じような処理を組み上げなくて良い環境になりました。
しかし、共通ライブラリが使用しているOSSフレームワークへの依存や、モノリシック構成な為、言語の固定化がされてしまうなど、
バージョンアップ、リファクタリング、機能追加、機能変更に弱い状態でした。
解決策
RESTfulなAPI型共通基盤の構築
- OpenAPIを利用
- OpenAPI generatorによるClientSDKの生成
- 外部パッケージリポジトリの利用
APIとして機能提供することにより、課題となっていたモノリシックな構成を解消できました。
基盤化によるメリット
共通基盤化することで実際のところどういったメリットがあるのか、こちらを紹介させていただきます。
新規開発のコストカット
決済など、外部IFへの繋ぎ込み系を新規で実装すると、「決済実装」「決済テスト」までで少なくとも 0.5~1人月程度かかってしまいます。
この部分を共通化しておくことで、新規実装として必要な実装工数が削減されます。
テスト工数の削減
新規で取扱を開始する場合でも、既存利用サービスの稼働によるコード実績があるため、後続で導入をするサービスにとって安全な導入と、テスト工数の削減が可能になります。
外部への接続IFの集約
決済であれば、決済代行サービス、Apple、Google、メールであれば外部メーリングサービスなど、外部IFを利用した処理を行う事がしばしばあるかと思います。
その時にサービス単位で外部サービスに接続をしていると、外部サービス側で変更、バージョンアップ等が生じた際にはサービス単位でその変更に応じて対応をする必要があります。
しかし、外部サービスのIFを基盤で吸収しておけば、基盤内部でのIF箇所を修正するのみで、サービス単位の修正は最小限にできます。
セキュア情報の隔離
昨今、どのサービスにおいても大小少なからず発生する個人情報管理のリスクヘッジが必要になってきています。
各サービスで補完していると、セキュリティレベル感の乖離が起きたり、リスクヘッジを管理する担当者がいなかったり、という問題が起きたりします。
そこで共通基盤でセキュア情報管理をし、サービスから隔離して補完することで、セキュリティレベルの統一化や、サービスより奥にDB等を配置できるので、漏洩リスクを大幅に削減できます。
サービスごとのデータ管理
マルチテナントを想定した設計として、論理レベルでデータ構成を分けることで、利用サービス単位でのアクセス可能な領域の管理、サービスがクローズになった際のデータ削除時のリスク低減も補えます
基盤化することの注意点
ここまで共通基盤化することでのメリットを紹介させていただきましたが、
一方で実際に運用してきた中で出てきた、いくつか注意点などを紹介させていただきます。
障害発生時の影響範囲が大きい
基盤自体のインフラ障害等が発生した時には、利用しているサービス全てに影響が出てしまいます。
共通化することで単一障害点になることを予測して組み立てる必要があります。
共通基盤では障害発生時には以下のように対応をしています
- Slackなどで対象サービスの担当者へ連絡
- 障害内容の切り分けがSlack通知でわかるようにシステムから通知
しかし、現状では基盤メンバーが気づけなかった場合にサービス側での影響範囲の切り分けが難しい状態になっています。
将来的には、APIステータスページや、エラー発生状況などがサービスからもわかるようなレポートページなどを用意し、誰でも影響範囲が把握できる状態を目指します。
特定サービスの短期的な高トラフィック
弊社のサービスの特性として、人気アーティストの公式サイトなどがあります。
そのため、リリース情報や、チケット選考など、情報公開された際に短期的なトラフィックの増加が発生することがあります。
通常サービス運用していく上ではトラフィックの増加はサービス自体のみ意識していれば問題ないですが、共通化する上では利用しているサービスのトラフィック上昇予測も把握しておく必要あります。
そのため、共通基盤として以下のような対応をしています
- 事前にサービスからトラフィック増大見込みをもらう
- 必要に応じて外部IFの暖機申請
- インフラの増強※
※Auto Scalingで間に合わないほどの短期トラフィックのケース時に対応
現状上記のような対応ですが、将来的にはサーキットブレイカーの導入をし、手動対応をしなくともトラフィック増加時に基盤側の負荷がサービスに波及しない設計を目指しています。
基盤サービス実例
ここまで基盤化することのメリット、注意点などをまとめましたが、
ここからは実際に運用している基盤サービスの一部を紹介させていただきます。
決済基盤
決済周りの処理、データを管理する基盤
サービス特有すぎる要件を除き、決済ロジックの全てを請け負います。
従量決済
- 決済会社への決済要求
- 決済ログの管理
継続決済
- 決済会社への決済要求
- 決済ログの管理
継続決済登録/退会
- 継続課金ユーザーのステータス管理
これらの処理を基盤におくことで、利用サービスは決済に紐づくデータについては保持する必要がなく、継続課金の管理も基盤側に任せることができます
セキュア情報管理
セキュアな情報をひとまとめに管理する管理基盤
漏洩した場合、リスクになりえる様な情報をサービスのDBなどから隔離して保持することで、漏洩リスクを下げることを目的としています。
現状はそのままテナント単位でのデータを保存するのみの基盤ですが、
現在リニューアルを進めており、将来的にはフィールドレベルの暗号化、フレキシブルに設定が可能なデータ格納を可能にする形でリリースを予定しています
ユニークID発行
グローバルでユニークなIDを発行する基盤
サービスを運用していく中で必ずと言っていいほど登場する、「ユニークなID」
この基盤ではグローバルでユニークを担保するIDを発行するシンプルな基盤サービスです。
ここの部分を基盤としておくことで、ユニークを担保、考慮するための処理の一切をサービス側は考える必要がなくなります。
動画配信
リアルタイム配信・オンデマンド配信を行う動画配信基
弊社では動画サービスも展開しているサービスもあるため、動画配信に向けての基盤も展開しています。
リアルタイム配信では、Wowza Streaming Engineを利用し、ストリーミング配信
終了後のデータについてはAmazon Elastic Transcorderを用いて画質パターンに分けてS3に保存しオンデマンド配信を可能に
また、単純に動画をオンデマンド配信用にアップロードして同じくElastic Transcorderを用いて画質パターンを分けてS3に保存、配信する、という機能を持たせています。
オンデマンド配信を利用する場合は、利用サービス側は配信用のトークンを用いてS3に置いてある動画ファイルを呼び出すことで動画視聴を可能にする仕組みとしています。
サーバーサイドレンダリング
サーバーサイドレンダリングを実施する基盤
SEO対策で用いられるサーバーサイドレンダリングですが、
各サービス単位で都度レンダリング済みページのキャッシュを保持させてbot対策しておく場合は、キャッシュの保持、保持期間、サーバーサイドでのレンダリング処理の準備が必要になります。
この部分を基盤化しておくことで、新規サービスが立ち上がっても動的ページのSEO対策がカジュアルに実行できる様になります。
まとめ
共通基盤を運用していた中で生まれたメリットと、注意点をまとめました。
共通基盤はシステムの公共施設として、安全性、利便性が求められるサービスです。
統合して管理、運用していくことは苦労する点も多いですが、
基盤化をしていくことで、長期的な全社的コスト削減と品質担保の実現を目指すことができます。
日々基盤チームメンバーは上記を意識しながら運用・開発を行っております。
直近ではセキュリティレベルを大幅に向上させた、個人情報管理の共通基盤の開発や、決済IFを最小限にまとめあげより使いやすさを目指して設計している決済基盤などの開発を進めています。
基盤というと堅いイメージがありますが、弊社基盤メンバーはこれからも新しいことへチャレンジしていき、日々開発を行っていこうと思っております。
以上、ご拝読ありがとうございました。