BaaS(Backend as a Service)勉強会に参加してきました

BaaS(Backend as a Service)勉強会に参加してきました

BaaS(Backend as a Service)勉強会に参加してきました。

勉強会の参加者のツイート内容は#BaaS (Backend as a Service) 勉強会のつぶやきログにてまとめられています。

以下のメモについては私のメモをまとめただけなので、内容に間違いがある可能性にご留意ください。

そもそもBaaSとは?(予習)

初めて聞くキーワードに関する勉強会の場合、予習しておかないとメモをまとめるのに苦労するため、あらかじめBaaSについて簡単に調べてみました。

BaaSとは

アピアリーズさんのBaaSとはの解説を引用すると、「モバイルアプリサービスの運用に必要な汎用的なサーバ機能を提供するクラウドサービスの一形態です。」とのこと。

  • モバイルアプリの開発はデバイス側(フロント側)、サーバサイド側、サーバの構築がセットになっている。
  • デバイス側で完結するアプリは殆ど例を見なくなっている。
  • モバイルアプリのサーバ構築では、以下の2点に頭を悩ませることになる。
    • スケーラビリティ
    • アイドルコスト(遊休コスト)

スケーラビリティとアイドルコスト

  • 自前でのハードウェア確保の場合
    • スケールアップの度にサービス停止が発生する。
    • 場合によっては新しいサーバへデータを移行する必要がある。
  • スケールアップの面倒がないように、始めから高性能なサーバを用意すると、今度はサーバが遊んでいる(アイドルコストが大きい)状態になってしまう。
  • スケールアウトの場合、入念な設計と高度なサーバ管理技術が必要であり、実施は容易ではない。

そういえば、WEB+DB PRESSのVol.78の特集記事「DMM.com開発ノウハウ大公開」でもDMM.comさんのサーバ機器の変遷(サーバラックの追加・増設やデータセンターの移行)が解説されていました。

これらの問題への解決方法としてクラウドサービスがあり、その一つとしてBaaSがある、という話のようです。

○aaS

また、BaaS以外にも○aaSと名前のつくサービスがあり、以下のような分類となっています。

図で表現すると、利用者側から見た○aaSの分類は以下のようになります。

f:id:furandon_pig:20140604213403p:plain

これらを踏まえてBaaS勉強会に参加してみました。

HTML5 Japan Cupについて

  • 発表者は白石俊平(html5j管理人)さん。
  • 発表スライドは以下のURLで公開されています。
  • html5jについて
    • 「日本が、世界のWebシーンをリードする存在になる。」を目標に掲げている。
    • わりと規模が大きくなってきた。
    • html5jのサブコミュニティ→14個くらいある。
  • 現在開催中のHTML5 Japan Cup 2014のお話。
    • Webデザイナー/Webエンジニア向けの、クリエイティブコンテスト。
    • HTML5 Japan Cup 2014のすごいところ。
      • 賞金すごい
      • 賞(と提供企業→42団体)すごい
      • 会社が開発者にコンタクトを取りたがっている→お仕事につながるかも、とのこと
    • 盛り上がる(希望)
    • 6/30まで作品製作期間、この間に作品をどんどん投稿して欲しいとのこと

HTML5開発者にとってのBaaS活用のメリット

  • 発表者は安藤幸央さん
    • そもそもBaaSとはどのようなものか?
    • サーバサイド開発用の言語が苦手な方でも、BaaSならサーバ機能を使った アプリを作れる!
  • 発表スライドは以下のURLで公開されています
  • BaaSの中にはサービスの中にはMBaaSに特化したものもある,
  • クラウドサービスを実際の天候に見立てた場合、晴れだけでなく、雨の日もある。これを避ける「傘」がBaaSであると考えている
  • 例えばfacebookのようなサービスをつくろうと考えた場合
    • フロントエンドだけでなく、サーバも作り込む必要がある(フロント-サーバの連系)
      • フロントは自分たちで作成し、バックエンドは既存のものを組み合わせて使おう、という考え
  • サービスを作る際に必要な機能
    • 認証、データの保存・管理、プッシュ・メール通知、アクセス解析SNS連系、課金、etc...
    • 基本的には定番の機能で、その都度(定番の機能を)作り直す形になる
      • バグ回避の観点からも、既存の実装済み機能を使いまわす方がよい
  • facebookとParse
    • 最近のBaaS関連のニュースで大きかったトピック
    • facebookが"Parse"というBaaSの会社を約84億円で買収した
    • 無料+使いやすくしたために、買収後の利用者が10倍になった
  • BaaS活用の観点
    • スピード、(人的)リソース、コスト、の3つが重要
    • スマホアプリ開発時の割合
      • 開発する前に設計
      • 開発→サーバ、クライアントの開発割合は50%/50%
      • BaaSを使うとクライアント側の開発に集中できる
  • BaaSの利用が向く開発
    • 開発エンジニアが少ない場合
    • バックエンドエンジニアのリソースが割けない場合
    • 一人で開発する場合
  • BaaSの利用が向かない場合
    • 開発メンバが多い場合orスキルの高いメンバが多い場合はBaaS不要
    • バックエンドエンジニアのリソースが確保できる場合
    • 一般的な機能の組み合わせでできるサービスを構築する場合
      • (BaaSを使うまでもない、という話?)
  • Instagramの開発エピソード(BaaSが無かった頃のサービス開発エピソード)
    • Instagramはクライアントサイド畑のエンジニアが2人で開発したサービス
    • そのため、サーバ側は手さぐりで作っていた
    • 最初の日に25000人が登録、一気に大量に使われるようになった
      • favicon.icoをサーバに置かなかったことで、「faviconが無い」というログで溢れかえってしまった
      • こういう失敗が無いようにBaaSを活用すればよいと考えている
  • 最適なBaaSを選択
    • BaaSベンダを選ぶ際の基準に関する話
    • (発表者のスライド(38枚目)を見てもらった方が良いかも...)
  • BaaSのデメリット
    • セキュリティ→ベンダが対応してくれる
    • ベンダロックイン→二つのサービスにまたがって動作させる、OSSのBaaSを活用
    • ダウンタイム→あきらめと、落ちる前提でサービスを企画する
    • テスト切り分け
    • 価格設定
    • 機能が足りない

現役BaaS開発者パネルディスカッション

  • モデレータは冨田慎一(株式会社マッシュマトリックス)さん
  • BaaS開発者として以下の方々が登壇されていました(敬称略)
    • 荒川義弘(株式会社アピアリーズ)さん
    • 石塚進(Kii株式会社)さん
    • 野田雄也(ニフティ株式会社)さん

各社のBaaSの特徴紹介の後、モデレータの方から出されたテーマを元にBaaS開発者の方が話すという内容でした。その後、参加者からの質疑応答タイムとなっていました。

モデレータの方から出されたテーマを元にBaaS開発者の方が話した内容

  • (テーマその1.)日本のBaaS市場、これから伸びてゆく?盛り上がってゆく?そして、ぶっちゃけ儲かっている?

    • アピアリーズさん
      • IIJさんと提携してからお問い合わせをいただくようになったので、勝手に盛り上がっていると考えている。
      • まだ儲かっているとこまでは行っていない。
    • Kii株式会社さん
      • 日本で盛り上がっているかと言われるとまだまだ
      • ただ、隠れて興味を持っている人・会社は多いようで、しずかに注目されていると思う
      • 儲けはまだまだだが、これからだぞというかんじ
    • ニフティ株式会社さん
      • 儲けはまだまだ
      • イベントに出典して問い合わせをいただいているので、企画で盛り上がってきていると思う。
      • 具体的なお問い合わせも多くなっており、(BaaSの盛り上がりは)これからだと思っている
  • (テーマその2.)海外のBaaSベンダーは40社以上あり乱立している。大手の会社もBaaSやろうとしており、海外勢をどう考えている?海外と自分たちのBaaSベンダの違いは何であると考えているか?

    • アピアリーズさん
      • 海外/国内の違い→日本語対応、サポート。
      • 日本国内でワンストップになるのが強みだと考えている。
    • Kii株式会社さん
      • モバイルでもローカルに特化するのも意味があると考えている。
      • マルチサイト対応しているので、日本で作って中国に持っていけるのは自分たちの強みだと考えている。
    • ニフティ株式会社さん
      • 一番大きいのはサポートが日本であること。
      • 企業で使おうと思うと早い時間で日本語でレスポンスがあるのはかなりのメリットと考える。
      • (データセンタが日本にあるので)レイテンシが低いのもポイント
        • が、海外からのレイテンシが大きくなるという逆の見方もあるとのこと
  • (テーマその3.)HTML5jカップでBaaSのからみで→MBaaSでモバイル、ネイティブアプリ/Webアプリという文脈でモバイルに限らずWebアプリを考えたときにBaaS利用はありえる?BaaS利用でHTML5はこれからどうなる?

    • アピアリーズさん
      • WebアプリでBaaSは十分にアリだと考えている。
      • アプリKeyが無くてもOKにしている、WebアプリとBaaSは親和性が高いと考えている。
    • Kii株式会社さん
      • アリだと思う。元々BaaSに'M'が付くのはMobile(の開発)が特殊だったから
      • Ruby on RailsとかはBaaSで置き換えてもよいのではと考えている。
      • ネイティブ/Webアプリの文脈→前者はbaaSある。
      • WebアプリはBaaSが取りに行ってないし、やろうという人もいない。我々としても後者にチャレンジしたいと考えている。
    • ニフティ株式会社さん
      • JavaScript SDKでキー書き出す。
      • セキュリティはsignatureチェック、機能制限をかけようという考えている。
      • PhoneGap→ブラウザオンリーでアプリが作成できるという開発環境。ライトなアプリはこれで十分。
  • (テーマその4.)今回の参加者からアンケートを取ったらサーバ系の人が多い。インフラ/DB/ミドルの構成教えて

    • アピアリーズさん
      • 概ねJavaで作っている。場合によってPHP,JavaScript
      • 基盤はIIJさんのGioクラウドを使わせていただいている。
      • DBまわりはメインでMongoDB。
    • Kii株式会社さん
      • 基本的にインフラはAWS、中国だけ別。
      • メインはJavaPython,NodeJS、ストレージは普通のRDBだったりMongoDBだったり。
      • ロックインされたくないので差し替え可能なように作っている。
    • ニフティ株式会社さん
      • IaaSはニフティクラウド
      • 開発言語はかなりの部分がJava
      • ミドルDBはMongoDB。
      • 他社様の構成も弊社と似ているのではと考えている。
  • (テーマその5.)言ってみればBaaSってサーバエンジニアをいらなくする技術なのでは?そう考えた時にサーバエンジニアのキャリアパスは?

    • アピアリーズさん
      • BaaSが出てきてサーバエンジニアがいらなくなることは無いと思う。
      • ラッキングやスイッチング部分では不要。構成を考える部分では必要。
      • BaaSでも通信、トランザクション、想定される負荷の検討しだいでは(レイヤが変わってくるけど)必要だと思う。
    • Kii株式会社さん
      • 今後はバックエンドとフロントエンドエンジニアは分かれてゆくと思っている。
      • AWSで同じ話が出ている。
      • オンプレミスデプロイや他サーバとの連系を考えるとサーバエンジニアはこれからも必要。
      • シビアなビジネスロジックやパフォーマンスが要求されるようなコストが厳しい場面ではサーバエンジニアが必要だと思う。
    • ニフティ株式会社さん
      • なくならないと思う。
      • BaaSを選ぶのはフロントエンドの人だけでなく、backendの人が逆にBaaSを選択してあげても良いと思う。
      • フロント側の知識を得ればフルスタックエンジニアに一歩近づく。サーバの知識は無駄にならない。
      • ゲーム系の顧客では(パフォーマンスの観点から)BaaS使わない顧客も多い。

質疑応答

  • Q1.BaaSを使ってmobile appを作ることを考えたとき、どういうアプリがBaaSに向いていると思いますか?

    • アピアリーズさん
      • 弊社のBaaSではキャンペーンアプリが多いという歴史があり、短期間、低コストであった。
      • ヘビーなアクセスがあるようなゲームは自前のインフラとか考慮したりする必要があるので向いてないと思う。
    • Kii株式会社さん
      • 我々が色々な企業さんと話すと、いろいろなジャンルに向いていると思う。
      • BaaSはテクニカルじゃない部分がある。
      • アプリを複数持つとバックエンドを共通化したくなる。
      • そのため、アプリではなく業務として共通化したいのでは。
    • ニフティ株式会社さん
      • 私もなんでもできると思っている。
      • IaaSと同じでun-controllableなものをどうするかという点ではBaaSも同じ。
      • un-controllableな箇所を許容できるならもつ、そうでないなら持たない。
  • Q2.将来どこで他社と差別化(機能、料金とか)を図ろうと考えていますか?

    • Kii株式会社さん
      • 弊社はマルチサイト、海外展開が差別科要因だと思っている。
      • 機能で差別化は難しい。使ってもらわないと差別化にならないから。
      • 開発者の不満感に反応して(機能が)進化してゆくと思う。
      • どのBaaSを選ぶかはぶっちゃけ好みだと思う。使って行くことで自然にノウハウがたまると思う
    • アピアリーズさん
      • 正直BaaSは汎用的な機能を安価に使えるように、が出所なので差別化難しいと考える。
      • IIJのお客様から業務系アプリのお話をいただくことが多い。
      • 今後の展開は汎用機能突き進む側とエンタープライズ向け特価の2つを進めると思う。
      • エンタープライズ向けが差別かの点だと考えている
    • ニフティ株式会社さん
      • 差別化難しいよね。
      • (弊社の場合)IaaSから持っているのは強みだと思う。
      • スマホアプリのノウハウを持っている会社との連合軍で進められるのが強みだと考えている。
  • Q3.(Kii株式会社さんはオンプレを提供しているが)なぜオンプレしようと思ったのですか?また、他の会社はオンプレやる予定はありますか?

    • アピアリーズさん
      • オンプレはOEMで提供を検討している会社が数社ある。
    • Kii株式会社さん
      • オンプレに踏み切った理由→エンプラ向けの需要があるから。
      • 米国のBaaS業者もエンプラに行っている。
      • 既にあるエンプラ(MEEP)を喰いに行っている。
    • ニフティ株式会社さん
      • オンプレの話は問い合わせが多々ある。エンプラ系で多い。
      • が、現状はできていない。検討は引き続き行っており、うまい方法があるか考えている。

飛び入りLT

質疑応答の後、自作BaaSサービスを作成された方の飛び入りLTがありました。福岡からの参加(!)とのことでした。

  • 発表者は@nobkzさん
  • Milkcocoaという自作BaaSサービスの紹介
    • エンドユーザがWebアプリを作れないか!という観点で作成した
  • あわせてflowerというグラフィカル言語の紹介
    • Raspberry Piの上でも稼働するようです

まとめ

BaaS勉強会のメモをまとめてみました。今回は予習をしていったので楽にメモをまとめられると考えていたのですが、やはり四苦八苦してしまいました。メモを取りながら話のつながりをリアルタイムにまとめあげるという要領のよさが必要そうです...。

ご注文はうさぎですか?第7羽からインスパイアを受けてHTML5で「ごちうさパズル」を作ってみた

ご注文はうさぎですか?第7羽からインスパイアを受けてHTML5で「ごちうさパズル」を作ってみた

ごちうさパズル

ご注文はうさぎですか?の第7羽Call Me Sister.のストーリー中で、ココアがパズルを完成させてしまうというエピソードがありました。

このエピソードからインスパイアを受け、「ごちうさパズル」を作ってみました。

あそびかた

選択した分割数(ピースの数)に応じて画像がパズルのピース毎にシャッフルされます。最大で81ピースまで選べるようにしてあります。ごちうさ本編中では4000ピースのパズルだったので、81ピースはだいぶ少ないですが、なかなか没頭できます。

解くのが面倒になった時は"RESET"ボタンを押すとパズルが元に戻ります。

ごちうさパズルの実装

パズルのエピソードを観た時、HTML5で実装できそうだと思い立ったのですが、実装で地味にハマるところが多かったです。

パズルのピースをシャッフルする際の乱数データの取得方法

パズルのピースをシャッフルする際、乱数を使ってデータをシャッフルしています。パズルのピースは重複しないため、値が重複しないように乱数値をあつめる必要があります。かなり昔のI/Oというコンピュータ雑誌に「重複しない乱数列を得る方法」的な投稿コラムがあったのですが、当時はその原理を理解できませんでした。

が、実際には難しい話ではなく、以下の方法で実現できます。

  • あらかじめ配列に値を入れておく(等差数列でOK)
  • 乱数の値を取得し、配列のインデックスとする(乱数の範囲は0〜(配列のサイズ-1))
  • インデックスが指す値を配列の末尾の値と入れ替える
  • 乱数の範囲を1減らす
  • 乱数の範囲が0より大きい間、処理を繰り返す

JavaScriptによるサンプルは以下のようになります。

var value_list = new Array(10000);

// あらかじめ配列に値を入れておく
for (var i = 0; i < value_list.length; i++) {
    value_list[i] = i;
}

var range = value_list.length - 1;
do {
    // 乱数の値を取得し、配列のインデックスとする
    var index = ~~(Math.random() * range);

    // インデックスが指す値を配列の末尾の値と入れ替える
    var tmp = value_list[index];
    value_list[index] = value_list[range];
    value_list[range] = tmp;

    // 乱数の範囲を減らす
    range--;
} while (0 < range);  // 乱数の範囲が0より大きい間、処理を繰り返す

for (var i = 0; i < value_list.length; i++) {
    console.log(value_list[i]);
}

上記のサンプルを試してみます。配列の中身を一行毎出力しており、単に行数をカウントした値とsort,uniqで重複する値を除去した行数の値が同じであることから、重複しない値であることが分かります。動作環境はNetBSD-6.1-i386です。

$ node sample.js | wc -l
   10000
$ node sample.js | sort | uniq | wc -l
   10000

値もシャッフルされています。

$ node sample.js | head
2537
6218
7624
7580
692
4295
2508
6329
1150
4781

Pemtium M 1GHz,データの件数1万件の場合で0.4秒程度の処理時間です。

$ time (node sample.js 2>&1 > /dev/null)

real    0m0.499s
user    0m0.462s
sys     0m0.020s

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1000MHz
stepping        : 5
cpu MHz         : 996.80
fdiv_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm

参考までに、取得した乱数値が重複していないか逐一確認する処理方法の場合と比較してみます。30秒程度かかっており、こちらはオススメできない方法となっています。

$ cat sample-bad.js
var value_list = new Array(10000);

for (var i = 0; i < value_list.length; i++) {
    var index;

    // 配列の値が初期値(-1)でない間繰り返す
    do {
        // 乱数の値を取得し、配列のインデックスとする
        index = ~~(Math.random() * value_list.length);
    } while (value_list.indexOf(index) != -1);

    value_list[i] = index;
}

for (var i = 0; i < value_list.length; i++) {
    console.log(value_list[i]);
}
$ time (node sample-bad.js 2>&1 > /dev/null)

real    0m31.960s
user    0m30.481s
sys     0m0.040s

HTML5 Canvasと画像サイズの関係

ごちうさパズルではピースの数を選択できるようにしています。そのため、画像の幅・高さと1ピースあたりの幅・高さが割りきれないことがあり、ピースを並べて行った結果、Canvasや画像のサイズをわずかにはみ出してしまうことがあります。

今回のケースで考えると、画像サイズは600x600で、パズルのピースはNxNとしており、49pcs(7x7)と81pcs(9x9)の場合に幅・高さが割りきれない値になります。当初、単純に四捨五入(Math.round())する方法をとったのですが、Firefoxでは動作するもSafariではおかしなピースが描画されるという、ブラウザの挙動の違いにハマってしまいました。

$ node
> 600/2
300
> 600/3
200
> 600/4
150
> 600/5
120
> 600/6
100
> 600/7
85.71428571428571
> 600/8
75
> 600/9
66.66666666666667

結果、割りきれないケースの場合は、扱う画像の範囲を少し小さく扱うことで対応しました。

> 600/9
66.66666666666667
> 66*9
594        /* 594pxを画像の幅・高さとする */

Canvas.strokeStyle()の設定

これは私がCanvasの仕様を把握できていなかっただけなのですが、Canvas.strokeStyle()などでストロークの色を変更すると、既に描画したストロークの色も一緒に変更されるようです(Firefoxでしか確認してないので、他のブラウザだと違うかもしれません)。描画したデータについても、内部的には状態を保持しているようです。

まとめ

ご注文はうさぎですか?第7羽のエピソードを元に「ごちうさパズル」を作ってみました。HTML Canvasまわりではブラウザ毎の挙動の微妙な違いにハマってしまいました。Canvasまわりは私の理解が追いついていないところもあり、もう少し調べてみようと思います。

「悪循環画像ジェネレータ」を作ってみた

悪循環画像とは

昨日くらいから、Twitter上で「悪循環コラ画像」というものが流行っているようです。元々はみやぎ県政だより(2010年12月号)http://www.pref.miyagi.jp/kohou/kenseidayori/backnumber/201012/special/special01.htmの薬物乱用防止の啓蒙記事にある、薬物依存の悪循環を示すイメージ図がオリジナルなのですが、妙に汎用性(?)があるのか、様々なジャンルでの悪循環コラが作られる状態になっています。

そこで悪循環コラ作成の一助になればと思い、「悪循環画像ジェネレータ」を作成してみました。ブラウザ上で文言を入力することで悪循環コラが作れるというものです。

悪循環画像ジェネレータ

URLは以下になります(2017/02/12追記:Bitbucketだと404 Requestが返されてしまうのでGitHub Pagesに引っ越しました)。

入力欄に文言を入力すると、オリジナル画像をテンプレ化(吹き出しの文字を消したもの)した画像に文言が反映されるという動作になっています。
(それしか機能がない……)

単に入力された文言をHTML5 CanvasのfillText()で描画するだけのはずだったのですが、<br>で改行できるようにしたところ、予想よりもちょっと複雑な処理になってしまいました。
というわけで、文言の中に<br>を入れると、改行文字として扱われ、かつ、配置も(ある程度)よきにはからってくれる動作になっています。

悪循環コラを作ってみる

簡単なサンプルとして、のんのんびよりの悪循環コラを作ってみました。
以下のような感じになります。

f:id:furandon_pig:20140104082917p:plain

このツールでさらに悪循環コラが増えてくれればと思います。

その他

このアプリケーションはTwitter Bootstrapを利用したのですが、あまり活用できていません。また、バージョンが上がったのか、デザインやレイアウトルールが以前(1年くらい前)と変わっているようでした。