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

テックポエム

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

はじめに

ユニフィニティーが提供しているUnifinity Platform製品群において、お客様がモバイルデバイスで業務アプリを使い始めるまでを簡単にまとめると次のようなステップが必要です。(すごく端折ってます)

  1. Unifinity Flowで業務分析を行う
  2. Unifinity StudioでUnifinityアプリケーションを開発する
  3. 開発したUnifinityアプリケーションをモバイルデバイスへ配布する
  4. Unifinity Application Playerでアプリを実行

この一連の流れのうち、Unifinity Studioで作成したUnifinityアプリケーションをモバイルデバイスへ配布する仕組みを担っているのがUniBaaS (Unifinity Backend As A Service) です。

現在運用しているUniBaaSは種々の問題点を抱えており、今回システムを刷新することとなりました。本稿では旧構成の問題点を振り返りつつ新構成の概要についてご紹介します。

mBaaS (mobile Backend as a service)

◯◯ as a serviceって沢山ありますよね。SaaS,PaaS,IaaS,HaaSあたりがよく耳にするキーワードではないでしょうか。

弊社製品に限らず、モバイルプラットフォームで業務アプリを運用するような場合は一般的に以下のようなバックエンド機能が必要となります。

  • 認証
    • サービスを利用するユーザーのアカウントを管理する機構
    • ユーザーやデバイスを認証する機構
  • ファイル配布
    • サービスが使用するファイル等を配布する機構
  • プッシュ通知
    • iOS向けのAPNs、Android向けのFCMやWindows向けのWNSを利用してモバイルデバイスにメッセージを配信する機構
  • データストア
    • NoSQLやRDB等のデータベース機能
  • アプリ内課金
    • アプリ内の課金アイテムの管理機構
  • アプリ内分析
    • クラッシュレポート等を開発元へエスカレートする機構
    • アプリ内の行動解析機構
  • API
    • ビジネスロジックを処理するAPI層を実装できる機構

(業務アプリの実装には実際のところ他にも多々必要な機能があろうかと思いますがあくまで一般論です)

これらのような機能を提供してくれるサービスがBaaS (Backend as a service) です。内容がほぼモバイル向けのサービスであることから、mBaaS(mobile BaaS)とBaaSはほぼ同義と考えて良さそうです。

これらの機能を全てスクラッチ開発することも勿論可能ですが、各ベンダーから提供されているmBaaSを利用することにより、開発コストの削減やサーバー運用コストの削減などの恩恵を受けることができます。

数年前はParseをはじめとし多数のベンダーがmBaaSを提供していましたが、ParseがFacebookに買収された頃から旗色が変わり、現在では淘汰が進み以下のようなサービスが提供されています。(主要なベンダーのみ)

mBaaSに関する比較は検索すれば各所に比較記事が掲載されているので割愛します。

旧構成のUniBaaSとその問題点

旧構成のUniBaaSでは、上記に列挙されている機能のうち、

  • アカウント管理機能
  • 認証機能
  • ファイル配布機能
  • プッシュ通知機能
  • APIレイヤー
  • データストア

を提供しています。

しかしながら、アーキテクチャーとしては結構残念なツギハギ構成となっておりました。

unibaas1.png

諸事情により旧構成のアーキテクチャ詳細については端折りますが、下記のような種々の問題点を抱えておりました。

  • 拡張性の欠如
    • 外部のBaaSサービスをバックエンドとして利用していたのですが、それが故に提供できる機能が外部サービスに完全に依存してしまい拡張が不可能
  • 社内運用に係る工数と信頼に足る運用
    • 契約企業が増えるたびに、BaaSサービスの設定変更、dockerコンテナの設定変更、データベースの領域設定など、(なぜか自動化されておらず)結構な人間系の運用工数が必要
    • 人間系運用工数が必要=オペレーションミスの原因が増える要因となっていた
  • 統合性の欠如
    • APIレイヤーの認証の入り口、BaaSの認証の入り口が別々という Platformとしては残念な構成
  • その他
    • もともとマルチテナント機能が無い外部BaaSサービスを無理やりマルチテナントに仕立ててサービス提供しようとしたことによる機能的・社内運用的なホコロビ
    • 顧客視点でないマニュアル
    • システムの構成要素が多いことに起因する稼働率の低さ

これらの問題点を解消すべく、旧構成のリファクタリングも検討しましたが、、、リファクタリングに係る各社調整を含めた工数とシステム刷新に係る工数はさほど変わりがないと判断し、システムの刷新を推進することにしました。

新構成については後編に続きます。