CA MOBILE TECH BLOG

株式会社シーエー・モバイルのエンジニア・デザイナーの活動を綴るブログです

株式会社シーエー・モバイルの技術広報による、
技術に特化したブログです。
エンジニアとデザイナーの活動や思想を綴ってゆきます。

CAM独自基盤システム「Camplat 」誕生秘話 〜砂漠に水道を作るような話〜

f:id:cam-engineer:20180814135348p:plain

「砂漠に水道を作る」ような仕事

シーエー・モバイルには「Camplat(キャムプラット)」という部署があります。CAM(=シーエー・モバイルの略称)+plat(=プラットフォーム・基盤)の造語で、その名の通り、CAMの基盤システムを構築・保守するグループです。

コモディティ化したものを基盤として構築する方針で、一般的に広く長く使われているものや、事業部にニーズがある機能を作ることをミッションとしています。

f:id:cam-engineer:20180814135604p:plain
▲ Camplat のロゴマーク。キーキャップと土台(台形)のWイメージ。

非エンジニアである筆者は、その”明示的な”ネーミングを聞いても、仕事内容が今ひとつピンとこなかったのですが、事例を交えつつ細かく話を伺ったところ、だんだん何かに似ている気がしてきました。

それは「砂漠に水道を作る」ことです。

それまでは、家ごとに井戸を掘ったり、川まで水汲みに行っていたところに、水道局を作り、浄水場・水道管を構築して、全ての家が均質の水を利用できるようにする。

それにより、新しい家を建てる時、水道管を引くだけで水道が使える。水質は中央で一元管理されるので、家ごとにそれを心配しなくてもよくなる。そういう事にすごく似ていると思いました。

蛇口をひねれば衛生的な水が出るという”当たり前”を作っている人がいるのと同様、安心してwebサービスの開発・運用できる背景には、その基礎を作って守っている人がいる。その事を、以下のインタビューで知りました。



部署の成り立ちとミッション

[ お話を伺ったのはこのお二人 ]
f:id:cam-engineer:20180814140630p:plain
野口 大介
2013年中途入社。サーバサイトエンジニア。芸能系ニュースサイト、受託案件、ゲーム会社のキャンペーン、アドテク周りを経験し、現在は社内基盤システムに携わる。Scala と森博嗣の小説が好き。
f:id:cam-engineer:20180814140627p:plain
根立 宗一郎
2004年中途入社。サーバーサイドエンジニア。FP公式課金サービスの開発・運用業務、電子書籍・SNS・広告系アプリ等多数経験。週末は家に引きこもる二児の父。Ruby on Rails での開発が好き。



— Camplat って何をする部署ですか?どうしてできたのでしょう?

野口: 決済システムやメアド登録機能といった、サイト構築に欠かせない6つのシステム・パッケージである「Camplat」の開発と提供をしています。部署名と同じ名前です。

昨今のコンプライアンス重視の流れもあり、個人情報など秘匿性の高い情報を集中管理できる基盤構築はマストでしたし、別のチームが進めているデータ分析基盤での将来的なデータ活用を見越して、流し込むデータを収集する基盤も必要でした。

これまで、ガラケーからスマホにプラットフォームが変わってくるタイミングで作られたレガシー・システムが使われてきたのですが、長い年月の間、サービス追加を繰り返して、タコ足配線のような複雑で危険な構成になってしまいました。

f:id:cam-engineer:20180814154457p:plain
▲ 旧・社内システムの構造。網の目のような複雑さに。

昔の話ですが、コスト削減が行き過ぎた結果、共通基盤の運用保守担当はコストとみなされて、長らく機能改善やセキュリティアップデートがなされず、大変リスクの高い状況にありました。

その後、エンジニア組織が新体制になって、必要なお金はちゃんとかけよう、という流れになって。そこで発足したのがCamplatです。


— わざわざ自社開発したのはなぜですか?

根立: 理由は色々あるんですが、主には社内での使いやすさを最重視したためですね。

CAMは多彩な事業を展開していますから、それぞれのビジネスモデルに最適化するためには、設計からそれに寄り添っていく必要がありました。

例えば、SendGrid(外部クラウドメール配信サービス)やSBPS (ソフトバンク・ペイメント・サービス)・PayPalなど、CAMが採用している他社製品への繋ぎこみ方を、社内で求められる形でカスタマイズすることで、より高い利便性を実現しました。

f:id:cam-engineer:20180814144523p:plain

社内で運用する数多くのサービスに展開しやすいよう、共通ライブラリのようなパッケージのスタイルにしました。

多忙な事業部付きのエンジニアを、可能な限り事業側の作業に集中させてあげたいという観点から、他社製品の仕様変更を自社製品(Camplat)側で吸収し、事業部側が個別対応に追われなくていいようにしました。



共通システム・Camplat の内容

— Camplat の6つのシステムの概要を教えてください。

野口: leaf、payment、guid、personal、mail、delivery というサイト構築をサポートする6つのシステムで構成されています。以下が、システムの個別の解説になります。

名称 機能 内容
leaf 決済基盤システム キャリア公式決済を提供する課金システム。Perl、PHP で構築されていた既存システムを Java でリファインしたもの。
payment 決済基盤システム いわゆる勝手サイトなどのためのキャリア決済やクレカ決済を提供する課金システム。
guid ユニークID割振システム 社内横断で、ユーザーのユニークIDを割り振れるしくみ。
personal 個人情報 個人情報をセキュアな状況で管理できるしくみ。
mail 空メール登録システム 空メールの送信でメールアドレスをキーとしたユーザー登録を可能にするしくみ。
delivery 配送基盤システム 商品をユーザーに配送する際、配送業者を取りまとめるしくみ。personal と連携することで、サービス側が受け手の住所等を意識・管理することなく、物品を送る事ができる。

どのシステムを導入するかは、事業部側のサービス形態によりますので、全部入れるところもあれば、一部だけ導入するケースもあります。



Camplat を導入する意義

— 事業部ごとではなく「共通」システムを進めるのはなぜですか?

根立: 各事業部ごとに仕組みを開発した場合、いわゆる「車輪の再発明」になります。学習目的でもないのに、共通化できる部分までそれぞれの部署で作るのは、全くの無駄です。

また、設計や実装内容など品質がばらついて、会社のサービスレベルを下げることになります。それに、個人情報などの重要データを事業部に点在させるのは、セキュリティリスクを高める結果になります。


— Camplat 導入のメリットは?

野口: まず、各事業部の開発工数を短縮できます。新規でサービスを立ち上げるのに、決済基盤を普通にゼロから作ると、簡単もので調査開始から1〜2ヶ月から半年かかるんですが、Camplatを使うことで工期が1〜2週間になるイメージです。

根立: 個人情報の管理ツールも同じで、ゼロベースで考えると、また1〜2ヶ月。

野口: 決済の場合、つなぎこむだけじゃなくて、整合とか関連する諸々も気にしなければならないので、実際、数ヶ月単位で(工期を)短縮できるんじゃないですかね。

f:id:cam-engineer:20180814144540p:plain

根立: 既存サービスに対してだと、ちょっと違った方面になりますが、ログの集約とか、セキュリティホール、キャリアの仕様変更等に追随していくための工数が削減できます。

野口: コスト以外にも、いくつかメリットがあります。

将来的には、先述のデータ分析基盤との連携ができて、事業部ごとのビジネス戦略に活かせます。

また、事業部のエンジニアにとっても良いことが多くて、外部システム(通信キャリアやクレジット会社の決済基盤、倉庫など)の存在を意識することなく、開発に集中できます。

またSDK(開発キット)を提供するので、事業部で使われている開発言語に関わらず、容易に導入できます。

根立: あと、サービス側の実装レベルの平均化も期待できますね。開発者のスキルに引っ張られることなく、品質が一定した開発が可能になりますので。

それに同じベースで開発することで、サービス間でのノウハウの共有も容易になります。


— デメリットは?「共通」システムはリスクも「共通」化しませんか?

野口: デメリットというか、当然ですけど、既存システムに導入する場合に多少の改修コストがかかります。(導入工数と削減可能工数の)プラマイの天秤にはなってしまうのですが、先々を考えたら導入のメリットの方が大きいと思います。

f:id:cam-engineer:20180814144545p:plain

根立:「リスクも”共通化”」の点で言うと、プログラムの問題とインフラの問題とで分けて考えなくてはなりません。

プログラムの問題的には、バグや仕様変更に引っ張られるなど、これまで同様にリスクはあります。これはどんな有名なIT企業のサービスでも同じで、絶対に0%にはできません。

しかしながら、インフラの問題的には、AWS 環境で構築しているのはもちろん、ECS でローリングアップデートすることによりサービスが安定してリリース・運用できる仕組みにしています。

また、Datadog でのリソース監視や、Bugsnag による問題検知を導入し、サービスの問題に素早く対応できるようにしています。


— 社内の共通システムはcamplatだけでしょうか?

根立: いえ、実は他にも3つほどあります。中には、導入できるサービスが限定的なものもありますが、orb(動画配信基盤)、calamari(リアルタイムデータ通信基盤)、ssrer(サーバサイドレンダリングツール)といったものがあります。

orb は、RTMP で送られてきたストリーミング動画データをメディアストリーミングサーバーに取り込み、そのままライブ配信できるようにする仕組みです。ライブ配信したものを録画し暗号化して、そのままオンデマンド配信することもできます。

ライブ動画配信は今、開発中のとあるサービスで9月頭にリリース予定で、VOD はしゅからんどラストアイドルに採用しています。

野口: calamari は、WebSocket を使って、クライアント間のリアルタイム通信を実現している仕組みです。

主にチャットシステムで使用しており、同時に数千人から数十万人ものクライアントを繋ぐ事ができるので、かなり大規模な施策に使えます。

最後の ssrer は、サーバ・サイド・レンダラーのことです。一般的には、JavaScript の処理を含んだコンテンツの生成をクライアント側で行いますが、ssrer を使用すると JavaScript の処理が完了した状態のコンテンツ生成までをサーバ側で行うことができます。

JavaScript の処理ができないクライアントなどに対しても、正しいコンテンツを返すことができる機能です。

まだ社内の導入事例は少ないのですが、主なところで DDTしゅからんどに採用しています。



インタビューを終えて

喜ばれる仕組みを作るためには、ニーズをぶらさずに捉えておく必要があります。

そのためには、「技術力」と同等かそれ以上に「聞く力・コミュニケーション力」、そしてその組織の過去の歴史や他部署のビジネスへの理解も同時に問われますから、仕組みを作るというのは、レベルの高い仕事と言えるでしょう。

「砂漠」に「水道」ではなく「砂の山」を作ったとしたら ——それがいかに高度な技術を用いたものであっても—— 喜んでもらえないかもしれません。

「砂漠に水道を作る」という冒頭の例えには、そんな意味を込めてみました。

今回は古参(20年弱)WEB企業の基幹システム面での変化の事例とともに、Camplat がなぜ作られたのかを紐解いてみました。

Camplat の6つの機能に関する深掘りは、別の記事の主題として残しておきたいと思います。

f:id:cam-engineer:20180814144515p:plain

(技術広報・桑田)