Unifinityを支える技術 - UniBaaS - 後編

テックポエム

本記事は Unifinity Advent Calendar 2018 の11日目の記事となります。

前篇からの続きです。

外部のBaaSサービスをどう使うべきか

一般的なコンシューマ向けのアプリやシステムにおいては、利用者がBaaSの存在を意識することはあまりありません。

しかしながら弊社のサービスにおいては、お客様自身が社内利用ユーザーの管理を行ったり、業務通知のプッシュメッセージ配信処理を行ったりと、お客様の管理者様が管理コンソールを利用して運用する必要があります。

弊社のようなケースで外部BaaSサービスを利用する場合、お客様に管理コンソールを提供するという観点から、外部BaaSサービスを隠蔽した管理画面を構築することが望ましいと考えます。

旧構成で利用していた外部BaaSサービスは機能としては充足しているものの、APIを駆使して弊社のプラットフォームの一部として設計すべきところを、UI含めほぼそのまま利用するという設計がよろしくありませんでした。

新構成の検討にあたり

以下のポイントを新UniBaaSの重要事項として検討しました。

  • Platformとしての位置づけ
    • 当社の製品群を構成する統合環境の一部として BaaS機能が提供できること
    • お客様にとってワンストップでユーザー管理・配信管理・開発が行える環境を提供できること
  • 柔軟な拡張性を持っていること
    • 今後、製品に関連するサービスを柔軟に足していける十分な拡張性を持っていること
    • 楽に社内運用を回していける(自動化できる)ように、機能面以外の運用面でも柔軟に拡張できること
    • お客様の増大にも柔軟に対応(スケールアウト)できる拡張性を持っていること
  • 楽な運用
    • サーバー運用に関する費用的コスト・人的コストを最小限に抑えること

時代はサーバーレス

新構成の構築の検討中に、APNコンサルティングパートナーのMMMさんをAWSさんにご紹介いただき、下記の構成のご提案をいただきました。

unibaas2.png

ご提案の構成においては、新UniBaaSの検討にあたっての重要事項をすべてクリアしていました。

セキュリティを重視し、どうしてもオンプレミス環境が必要だ!というお客様がまだまだいらっしゃいますが、クラウドネィティブなサーバーレスアーキテクチャーはデベロッパにとってまさに福音であり、弊社も一部の機能をAzure FunctionsAzure Cosmos DBで組み合わせて運用していた実績もあり、AWSネィティブなアーキテクチャーで再構築することを決めました。

サーバーレスアーキテクチャーの大きな特徴のひとつが、サーバー運用を意識することが無いという点。

  • OSやミドルウェアにセキュリティパッチを当てるため、年に数回サービスを止めてパッチ当てしなくても良くなる
  • あらかじめキャパシティプランニングをしておき、それ相当の資源(CPU・メモリ・ストレージ等)を用意しなくても良くなる
  • アクセス増大にともなうスケールアウト構成などを検討しなくても良くなる

他にも多々ありますが、運用者はサービスの運用に専念することができ、上記のようなサーバ運用から解放されるという絶大なメリットがあります。良い時代になったものです。

(Azureで実装していたものはその後すべて go-lambda へ置き換えました)

オンプレミスをご所望のお客様はどうするの

サーバーレスアーキテクチャーの最大のデメリットが、究極のベンダーロックインであるという点。いったんクラウドネィティブでサービスインしてしまうと、開発から運用まで全てがクラウド側のサービスに依存してしまうこととなります。

このポイントに直結するのが、どうしてもオンプレミス環境で動かしたいんだけど、というお客様への対応。

これからの大きな課題の一つなのですが、今のところ以下のような解法があります。状況に応じ最適解を模索予定です。

  • AWS Direct Connect等の専用線サービスでセキュリティを担保する
    • 論理的にはお客様の要望をセキュリティ面で実現できますが、そもそもユーザー情報等を自社外に置きたくない、等の精神的障壁をクリアできるかが問題
  • AWS Outpostsでクラウド環境をそのままオンプレミス環境へ
    • Azureは Azure Stack、GCPはGKE On-Premなどでオンプレミス環境へのサポートがありますが、AWS Outpostsは2019年提供予定です。また、(きちんと調査できていませんが)お客様に負担いただくイニシャルコストが相当なものになりそうです。
  • クラウドに依存する部分をオンプレミス環境でも動作するようリファクタリング
    • 最終手段。フロントエンド(SPA)側はほぼ修正なしで移行できるはずですが、バックエンド側のクラウドネィティブな実装をオンプレミスでも動作するミドルウェアへつなぎ直すリファクタリングが必要。

今後の取り組み

新UniBaaSのサービスは2019年1月のカットオーバーを予定しており、起稿時の2018年12月現在では、AWS側の試験をするとともに、Unifinity Playerの新BaaS対応を進めています。

自信をもってリリースいたしますので、ぜひご利用いただければと思います。

柔軟に拡張可能なプラットフォームを手中にしましたので、今後は、Unifinityのロジックから利用可能なクラウドデータベースやマーケットプレイス等、Unifinity Platformとしての機能をUniBaaSから多種提供することを計画中です。

UniBaaSの機能追加や、AWSのサーバーレス環境の詳細、運用などについても今後ご紹介していきます。