まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:cloud

本ブログエントリは IBM Cloud Advent Calendar 2019 に参加しています。12/03 ぶんのネタです。経緯を紹介する導入部分がちと長めですが、お付き合いください。

あまり公に宣伝したりしてなかったのですが、以前に「空耳アワー・マシーン」を作ったことがありました。「空耳アワー」はテレビ番組「タモリ倶楽部」の人気ミニコーナーのあれです。 「外国語で歌われた歌詞が日本語だとこう言っているように聞こえる・・・」という空耳にフィーチャーした紹介コーナーです。ちょっとググってみただけで多くの傑作作品動画が見つかります:
2019112100


この空耳は、曲に合わせて歌われる外国語の歌詞の中で、「日本語だとこう聞こえる」という特徴ある部分を見つけることで成立しています。ふと「・・・これって自動化できるんじゃないか?」と閃いたのが「空耳アワー・マシーン」誕生のきっかけでした。いわゆる "Speech to Text"(音声のテキスト化)機能を使い、外国語の歌唱部分を(その言語ではなく)強制的に日本語でテキスト化する、というロジックです。実装にあたっては IBM Cloud から提供されているWatson Speech to Text API を採用しました。ちなみに Watson Speech to Text はライトプランと呼ばれるプランで利用する場合であれば、各種カスタマイズを行うことはできませんが、毎月 500 分ぶんの音声データ変換までは無料で利用することができます(2019年11月現在)。

実装したソースコード(Node.js 用)はこちらで公開しています:
https://github.com/dotnsf/soramimi

2019112801


ソースコードを git clone するかダウンロードして、settings.js 内で Watson Speech to Text API 用の API キーを指定すると実際にウェブブラウザで動かすことができるようになります。


ウェブブラウザを起動してアプリケーションにアクセスすると、最初にブラウザがマイクの使用許可を求めてくるので「許可」します:
2019112101


画面を下の方にスクロールすると「どの言語でテキスト化するか」を選択するボックスがあります。「空耳アワー」の場合ここは日本語固定ですが、機能としてはここで指定する別言語でも認識→テキスト化を行うこともできるようになっています:
2019112102


言語を指定したらマイクを持った人のアイコン部分を1回クリックして、枠が赤になる(録音モードになる)ことを確認します。枠が赤になっている間に英語の歌をマイクから「歌ってください」(笑)。歌い終わったらもう一度人のアイコンをクリックします。枠は水色に戻り、録音モードも解除されます:
2019112103


録音モードからモードが解除されると同時に、録音された内容が Watson Speech to Text API に渡され、「日本語でどう聞こえたか?」の結果が表示されます:
2019112804



一応、動くには動いています(よね?)。このアプリではマイクを使ってその場で録音した音データを使って日本語テキスト化を行っていますが、理屈の上ではこの入力を外国曲の MP3 データなどに切り替えればいいはず・・・と考えていました。

・・・が、いざそのように使ってみると、仕組みとしては動くのですが、期待していたほどの精度では認識してくれませんでした。もともと Speech to Text 機能は「喋った内容のテキスト化」に最適化されたものであって、「歌った内容のテキスト化」ではないという違いに加えて、「BGMによるノイズ」の影響が多分にあるように感じられました。要するに曲の中で楽器で演奏される部分が Speech to Text 的にはノイズとなってしまい、思っていたほどの精度でテキスト化できなくなっているようだったのでした。 まあネタとしてはある程度使えるが、正しくテキスト化できる箇所が少なすぎて実用(?)にはほど遠い、というものになってしまったのでした。これも公開を控えていた理由の1つでもあります:
2019112802


さて、長い導入部分が終わりました。ここまでが「空耳アワー・マシーン」を「作ってみた」という話で、ここからが本エントリのタイトルでもある「改良してみた」部分です。最近、音楽ストリーミング事業を展開している Deezer 社から spleeter というものすっごいライブラリが公開されました:

無料で曲からボーカルが抜ける音楽素材分離エンジン「Spleeter」公開
2019112104


この spleeter は TensorFlow を用いた機械学習によって音源からボーカルやドラム、ベースといったパーツを抜き出して分離することができるようになる、というオープンソースなライブラリです。音楽ストリーミング事業を展開している Deezer 社の立場を最大限活用し、大量のサンプリングデータを所有している状態で機械学習を行うことができ、その成果をオープンソース化して公開していただいたことになります。ウェブ上のパフォーマンスや精度に関する評判もよいものばかりという印象です。

この spleeter を使うことで上述の空耳アワー・マシーンの BGM ノイズ問題を解決できるのではないか、と考えました。BGM が Speech to Text のノイズとなっていた問題に対して、spleeter で曲データからボーカルデータだけを抜き出しておいて、そのボーカルデータに対して Speech to Text を実行することでノイズのない音声データからのテキスト化が実現できるのではないか!? と考え、これも実装してみました:
2019112803


この機能を実装するためには、あらかじめサーバー上に spleeter を導入しておく必要があります。そして spleeter をインストールする際にはパッケージ管理ツールである conda が必要になります。というわけでまずは conda (今回は簡易版の miniconda)を導入します。このページから自分のシステム環境にあった miniconda のインストーラーを選択してダウンロードし、実行して導入します:
2019112101
(↑画面は Linux 版 Miniconda のダウンロードリンクを選択する箇所)

miniconda 導入後に spleeter を導入します。コードは github で公開されているので、以下の手順を実行します:
$ git clone https://github.com/deezer/spleeter

$ conda env create -f spleeter/conda/spleeter-cpu.yaml

これで spleeter の導入が完了しました。spleeter を利用するにはまず以下のコマンドで spleeter をアクティベートし、・・: 
$ conda activate spleeter-cpu

続けて spleeter をテスト実行します。spleeter フォルダの中にサンプルの mp3 ファイル(spleeter/audio_example.mp3)があるので、これを使って実行してみます。今回はボーカルとそれ以外(2stems)に分割し、実行結果を output フォルダ以下に作成する、というオプションを指定して実行してみました:
$ spleeter separate -i spleeter/audio_example.mp3 -p spleeter:2stems -o output

成功すると ./output/audio_example/ というフォルダ(フォルダ名はファイル名から生成される)が作成され、その中に vocals.wav と accompaniment.wav という2つのファイルが生成されています。vocals.wav がボーカルだけを抜き出したもの、accompaniment.wav がボーカルを抜き出した残りの音源です:
2019112102


実際に audio_example.mp3(元の曲)と、vocals.wav(ボーカルのみ) / accompaniment.wav(ボーカル以外)を聴き比べてみるとわかるのですが、信じられないくらいキレイにボーカルが分離されています。これが無料でできるとは驚き!

audio_example.mp3(元の曲)
vocals.wav(ボーカルのみ)
accompaniment.wav(ボーカル以外)



そしてこれを上述の空耳アワー・マシーンに組み込んでブラウザから実行できるように改良してみました。この拡張機能は上述のソースコードにも含まれているので、こちらの機能を試す場合はアプリケーション実行後に /spleeter.html にアクセスすると、mp3 の音楽ファイルを指定して実行することができます(結果は out/ フォルダ内に作成されます):


そして実行してみましたが・・・ 想定外だったのは処理時間でした。例えば5分程度の曲を対象にした場合、これまでは単に Watson Speech to Text を実行するだけで、その処理時間が1分を超えるようなことはなかったのですが、spleeter でのボーカル抜き出し処理だけで5分前後かかるようになりました(ちなみに自分の PC のスペックは i5-8350 の8コアCPUでメモリは 8GB)。これは処理内容を考えるとかなり高速な処理であるとは思いますが、これまでと比べると、1曲単位での処理にかなり長い時間がかかるようになった、という印象です。 またその長い処理の間、CPU やメモリはほぼフル稼働となります。仮にネット上から利用できるサービスとして作ろうとすると、かなり高いスペックのサーバーインスタンスを用意する必要があることに加え、タイムアウトとの戦いも意識して実装する必要がある、という印象を持っています。 といった背景もあって、現時点ではバッチでまとめて処理して後から結果を確認する、という方向での実装が中心です。


一方、この処理によって得られた結果は spleeter で分離する前とは比較にならないほど良質でした。Watson Speech to Text API は日本語としてある程度の確信度をもって認識出来なかった部分は結果に含まれない(つまり正しく認識できた部分のみが結果として得られる)のですが、分離前は「あー」とか「うー」とかいうコーラス部分を除くとほんの数箇所だけが識別できていたのですが、分離後の結果のサイズは数倍になりました。つまりボーカルだけを対象とすることで識別可能な音声が数倍になった、ということになります。なお上述の vocals.wav (ボーカルのみ抜き出したオーディオデータ)を Speech to Text で変換した結果は以下になりました:
{
  "status": true,
  "results": [
    {
      "alternatives": [
        {
          "timestamps": [
            [
              "令和",
              2.37,
              2.77
            ],
            [
              "OSS",
              2.77,
              3.77
            ],
            [
              "は",
              3.77,
              3.88
            ],
            [
              "萌え",
              5.96,
              6.25
            ]
          ],
          "confidence": 0.38,
          "transcript": "令和 OSS は 萌え "
        },
        {
          "transcript": "令和 OSS は 親 "
        },
        {
          "transcript": "映画 を SNS は 萌え "
        }
      ],
      "final": true
    }
  ]
}

↑確信度は 0.38 とあまり高くありませんが、データの 2.37 秒から 6.25 秒部分が赤字のように聞こえた、という結果です。


「本当に空耳アワーでそのまま即採用されるレベルの空耳が検出できるか?」という観点においては残念ながら難しそうな印象を持っています。特に Watson はエロネタは不得意っぽい(?)のか、結果にエロなワードは皆無でした。まあこのあたりは有料版の Watson Speech to Text でカスタマイズすると変わってくるのかもしれませんが・・・ ただそのまま採用されるようなレベルでの検出はできなかったとはいえ、ここで検出された結果をヒントにそれっぽいワードを混ぜて改良すればもしや・・・ という期待は充分に持てる結果になりました。一ヶ月に 500 分、1曲5分とすれば一ヶ月で約 100 曲ほど無料で空耳を調査できることになります。あのTシャツを狙って・・・はまだ遠い夢かもしれませんが、(個人的に欲しい)耳かきあたりは狙えるんじゃないか・・・と期待が膨らむ結果となりました。

MIT(マサチューセッツ工科大学)が開発した教育用プログラミング環境「スクラッチ」は、ウェブブラウザでこちらのサイトを訪れることで利用することができます。一般的にはこの方法で利用することが(後述の方法と比較して常に最新版が利用できる、といったメリットもあり)推奨されます:
2019112001


最新バージョン(2019/11/18 時点では 3)と比較しての互換性などはありませんが、バージョン 1.x ではメッセージングによる外部連携を行うことができました。このバージョンは、今でもダウンロードしてインストールすることで自分の環境から利用することができます:
https://scratch.mit.edu/scratch_1.4


2019年11月現在、普通にスクラッチを利用する場合の環境は上述2つのいずれかになると思っています。ただインターネット環境に制約があるケースなど、特殊な環境でも最新版を利用することができないわけではありません。今回はそのような特殊なケースを想定し、Kubernetes (以下 k8s)環境の中にインストールしたスクラッチを使う方法を紹介します。

なお、以下つらつらと記述していますが、そんなに特別なことを書いているつもりはなく、「ごく普通に k8s に MIT スクラッチのイメージをデプロイ」しているだけです。どちらかというと自分の備忘録としてのブログエントリです。


【準備】
まず k8s 環境を用意します。独自にインストールした k8s 環境でもいいし、minikube 環境でもいいし、クラウドベンダーのサービスを使うもアリです。自分の環境からの利用に支障がないものを使ってください。なお以下では IBM Cloud から提供されている IKS(IBM Kubernetes Services) を使った例を紹介しています。IKS の場合は kubectl コマンドに加え、ibmcloud コマンドの導入も必要になります。詳しくはこちらを参照ください:
https://github.com/dotnsf/iks-handson/tree/master/Lab0

また minikube 環境を Windows 10 + WSL 環境下で作る場合の手順は以前のブログエントリで紹介したことがあります。こちらの環境を使う場合は以下を参照ください:
Windows 10 に minikube を導入して WSL から利用する


以下の手順に進む前に ibmcloud コマンドを使った IBM Cloud へのログインや環境変数の設定などを済ませておくようにしてください。詳しくは上述のリンク先を参照ください。


【デプロイ】
MIT スクラッチの docker イメージを使って k8s 上にデプロイします。今回はこのイメージを使わせていただきました:
https://hub.docker.com/r/kadok0520/mit-scratch3

(↑ MIT スクラッチ version 3 の docker イメージのようです)


デプロイ手順は以下になります(以下では mit-scratch3 という名称でデプロイしています):
$ kubectl run mit-scratch3 --image=kadok0520/mit-scratch3

$ kubectl get pod (pod の状態を参照し、 READY が 1/1 になっていることを確認)

NAME                                READY   STATUS    RESTARTS   AGE
pod/mit-scratch3-795d945bcb-2mj2b   1/1     Running   0          16h



"kubectl get all" の結果、mit-scratch3 の pod が動いていることが確認できました。

このままだと外からの利用ができないため、ポートフォワーディングを使って公開します。イメージのドキュメントによると、このイメージは内部的には 8601 番ポートを使って動作するようなので、このポート番号を指定して expose した上で、service の状態を確認します:
$ kubectl expose depoyment mit-scratch3 --type="NodePort" --port=8601

$ kubectl get service mit-scratch3 (service の状態を参照し、 POST を確認)
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mit-scratch3 NodePort 172.21.228.178 8601:32686/TCP 16h

"kubectl get service" の結果、mit-scratch3 は 32686 番ポートで外部公開されたことが確認できました。

また、このサービスのパブリック IP アドレスも確認します。パブリック IP アドレスの確認方法は使っている k8s 環境によって異なりますが、IBM Cloud の IKS の場合であれば次のコマンドで確認できます("mycluster" 部分は作成したクラスタの名称):
$ ibmcloud ks workers mycluster

OK
ID                                                     パブリック IP   プライベート IP   フレーバー   状態     状況     ゾーン   バージョン
kube-bn92ui5d00ng3ftqj7gg-mycluster-default-00000052   184.173.5.49    10.47.84.230      free         normal   Ready   hou02    1.14.8_1538

上記例であれば 184.173.5.49 がパブリック IP アドレスとなっていることが確認できました。つまりこの例であれば、ここまでの結果から http://184.173.5.49:32686/ にアクセスすることで k8s 環境内にデプロイされた MIT スクラッチにアクセスできる、ということになります。


【動作確認】
上記手順で確認した URL にウェブブラウザでアクセスして動作確認します:

2019111800


動いているようです。


【後作業】
作成した環境(pod, service, deployment)を削除するには以下のコマンドを実行します:
$ kubectl get all (mit-scratch3 の pod, service, deployment が存在していることを確認)

$ kubectl delete deployment mit-scratch3 (deployment を削除)

$ kubectl delete service mit-scratch3 (service を削除)

$ kubectl get all (mit-scratch3 の pod, service, deployment が削除されたことを確認)




このブログエントリの続きです。IBM CIS(Cloud Internet Services) とその設定方法についてはこちらをどうぞ:
IBM Cloud で CIS を使って証明書作成なしにカスタムドメインの https アクセスを行う


上記リンク先の設定を行うことで、アプリケーションファイアウォールや DDOS 対策など、簡単に安全なインターネット運用環境を構築することができます。これはこれで便利なのですが・・・

一方でこの設定が不要なタイミングもあります。典型的な例は「アプリケーション開発時」です。CIS の防御モードが有効になっている環境では、ウェブブラウザからアクセスした時にいったんそのリクエストを受け取った上で「そのリクエストが攻撃でないことを確認」します:
2019110706
 ↑リクエスト確認中の画面

 ↓問題ないと判断されるとオリジンサーバーへ転送されます
2019110707


つまりウェブブラウザからのアクセスであればリクエストの転送機能を使って安全なアクセスが可能になる、という仕組みで実現されています。サービスの運用段階であれば、これが問題になることはあまりないと考えられます。

一方でサービスの開発段階においては少し事情が異なります。API の単体テストなど、ウェブブラウザを使って行うこともありますが、curl などのコマンドやツールを使って行われることも珍しくありません。この場合、curl のリクエストに対して上記「リクエスト確認中」画面の HTML が返ってくるだけで、確認された結果のレスポンス(テストではこれを知りたい)が返ってくるわけではないのです:
$ curl https://XXXXX.XXXXX.com/api/users

<!DOCTYPE HTML>
<html lang="en-US">
<head>
  <meta charset="UTF-8" />
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
  <meta name="robots" content="noindex, nofollow" />
  <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" />
  <title>Just a moment...</title>
  <style type="text/css">
    html, body {width: 100%; height: 100%; margin: 0; padding: 0;}
    body {background-color: #ffffff; font-family: Helvetica, Arial, sans-serif; font-size: 100%;}
      :
      :
  ↑青字部分はリクエスト確認中画面の HTML 、これでは動作確認にならない


つまり開発段階で CIS を使う場合、ドメイン設定や SSL 対応などはそのまま使えますが、防御モードに関しては一時的に無効にしたくなるケースが出てくるのでした。この防御モードを無効にするための設定方法を紹介します。


といってもその手順は極めてシンプルで、サービスモードを無効にするだけです:
2019111500


この解除を行うことでドメインの DNS や SSL 対応などを残したまま、防御チェックだけを一時的に無効にすることができるようになります。



IBM Cloud から提供されている、Web コンテンツ向けにセキュリティやパフォーマンスといった非機能要件を統合的に設計するサービス、それが CIS(Cloud Internet Services)です。mybluemix.net などの IBM Cloud から提供される標準ドメインではなく、独自ドメインを使うことが前提となりますが、そのドメインで運用するウェブアプリケーションやコンテンツ全般を保護して、安全なインターネット環境を提供することができる便利なサービスです:

https://www.ibm.com/jp-ja/cloud/cloud-internet-services
2019111600


この CIS は(独自ドメインの)DNS を使うことでオリジンサーバーとは別の( Cloudflare 社の)サーバーを経由してオリジンサーバーにアクセスします。この中間サーバーを経由することで必要なセキュリティ要件やコンテンツ保護要件を提供する、というものです。

この CIS を利用して、クライアント(ウェブブラウザ)からの SSL(https) 通信を実現するには大きく3種類の方法があります:

(1)クライアント→中間サーバー→オリジンサーバー 間すべての通信をセキュアに行う方法
(2)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は自己証明書を使った暗号化通信を行う方法
(3)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は HTTP 通信で行う方法
2019110703


①、②、③いずれも共通でクライアントと中間サーバーとの間はセキュアな SSL 通信を行います。中間サーバーとオリジンサーバー間の通信をどう考えるか、という点が異なります。ざっくりいうと①がもっともセキュアで、③がもっともセキュアでない方法となります。

①は理想的といえる方法で、全ての区間がセキュアな通信となります。②も通信自体は SSL で暗号化通信となりますが、その際に利用する証明書はいわゆる「自己証明書」となります。①と比較すると(外部の業者などを使わずに)自分で証明書を作ることができるので、コストや有効期限の自由度などの面でメリットがありますが、「要は誰でも(ドメインのオーナーでなくても)作れる証明書」を使った暗号化通信を行う点が異なります。この証明書を普通に使って直接 SSL 通信を行うと、普通は「セキュアな通信でないが、それでも通信するか?」といった確認メッセージを経て通信可能になったりしますが、中間サーバーとして CIS を入れることにより、クライアントはそういった手順を経ずに通信できるようになります。

そして③の方法ですが、これは中間サーバーとオリジンサーバーとの間の通信は暗号化しない方法です。セキュアかどうか、という観点では暗号化しない経路が存在しているわけで他の2つよりは劣っています。一方で、この方法では証明書の作成を必要としません。クライアントから見た証明書は CIS の中間サーバーが自動で発行されたものが使われ、オリジンサーバーには(そもそも暗号化通信をしないので)証明書が不要です。開発段階や試験段階など、インフラに関わる権限が小さい状況下で、かつ(API の仕様など)https 通信が必須となるような場合においては非常に有要な選択肢となります。またこの方法であれば(そもそも取得しないので)証明書の有効期限切れを心配する必要もありません。 また特にオリジンサーバーとして IBM Cloud の PaaS 環境を利用する場合であれば、オリジンサーバーのルーティングを編集してカスタムドメインでのホスト名でしかオリジンサーバーにアクセスできないように設定することで(HTTPS を使わずにアクセスするような)迂回路を遮断する設定にすることも可能です。

今回はこの③の方法でカスタムドメインの https アクセスを行うための設定を紹介します。

まず IBM Cloud の CIS サービスを利用してプロビジョン済みの状態とし、普通にドメインを登録して設定します。その上で「セキュリティ」カテゴリーの「TLS」内で動作モードを「クライアントからエッジ」に設定します(これが③の通信のための設定となります):
2019110701


なお、このモードの設定内容によって上記図の①~③の通信方法が変わります。以下のような関係です:
2019110704


また DNS の CNAME でオリジンサーバーとの紐付けを行います(下図の「信頼性」-「DNS」)。このカスタムドメインの頭につけるホスト名を指定して、CNAME の参照先となる別名を指定します。IBM Cloud の PaaS (米国南部リージョン)を使う場合は参照先を us-south.cf.cloud.ibm.com を指定します。また「プロキシー」を有効にします:
2019110702


なお、ここで指定する参照先と IBM Cloud PaaS のリージョンとの関係については以下を参照ください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains

最後にオリジンサーバー側を用意します。IBM Cloud PaaS の場合であれば(CNAME で指定した名前).mybluemix.net でアクセスできるようなアプリケーションサーバーを CloudFoundry ランタイムとして作成します(このルーティングは最終的に削除します)。


また IBM Cloud PaaS の場合は「管理」メニューからカスタムドメインを登録する必要があります。この手順の詳細はこちらを参照ください(このリンク先では証明書をインポートする手順まで紹介していますが、今回ここでは SSL の設定を行う必要がないので不要です):
http://dotnsf.blog.jp/archives/1075713365.html


最後に上記で作成した Cloud Foundry ランタイムのルーティングを編集します。経路の編集から「経路の追加」を実行し、mybluemix.net ドメインと同じ名前を指定したカスタムドメイン用の経路を追加します(証明書をインポートしていないので鍵マークには×がついているはずです)。そしてもともとの mybluemix.net 側の経路を削除します。これでカスタムドメインを使った指定でないとアクセスすることはできなくなりました。最後に「保存」します:
2019110705


この状態でカスタムドメインを指定したホスト名で https アクセスを行ってみます。まず最初に CIS がリクエストを受け取ってアクセス内容を(アタックに相当するアクセスでないか)判断します:
2019110706


問題がないと判断されるとオリジンサーバーにルーティングが行われます。結果的に証明書を独自に発行することなくカスタムドメインを使った https 通信ができるようになりました:
2019110707



【参考】
IBM Cloud Certificate Manager で Let's Encrypt 無料 SSL 証明書を取得する



マンホールマップの新バージョンを開発中です。暇を見つけて開発しているので、作業が進む時期も進まない時期もあったりしていましたが、とりあえず最低限の機能の実装はできつつあり、だんだんアプリケーションとしての形になってきました。まだ開発中なので、画面は変更する可能性もありますが、一部の機能をチラ見せしつつ予告編のような形で紹介します。


【新バージョンのテーマ】
ずばり「地図へのこだわり」と「技術の無駄遣い」です。現行版もおなじテーマで開発しており、マップのネーミング通り、地図機能にこだわりつつも、人工知能など比較的あたらしい技術要素を含んだりしていましたが、自分的にはそろそろ更に新しい技術テーマにも挑戦したいと考えていました。既存バージョンからの機能拡張では済まないような、基盤よりの新技術テーマにも挑戦したかったので、新バージョンという形でまったくゼロからのスクラッチ開発に取り組みました。

ちなみに開発言語は現行版が Java でしたが、新バージョンでは Node.js を使います。過去のマンホールマップのプラットフォームは Google App Engine だったり、J2SE だったりしましたが、開発言語はずっと Java を使っていました。その意味でも全くのゼロからの作り直しとなります。


【新バージョンの技術目標】
大きなものは以下の3つです:
- レスポンシブ対応を含めた新ユーザーインターフェース
- ハイブリッドクラウド化
- ブロックチェーン対応

「レスポンシブ対応」とは「PC ブラウザでもスマホブラウザでも、使っているデバイスの画面サイズにあわせてそれなりに使えるようにする」ことを意味しています。現行版も一応スマホ対応していますが、これはスマホ用の画面を PC 用とは別に作っていて、「スマホの人はこっちのページ」という対応でした。 この方法はメンテナンス時に互いの影響を少なくすることはできますが、2つのアプリを同時に開発するような側面もあって、開発する側としては面倒なものでもありました(現実的にはスマホからは使えない機能も多くあります)。 今回ははじめからレスポンシブ化を目指して開発を進めています。今の所 100% レスポンシブ対応できるようになるかどうかは微妙な予感がしていますが(苦笑)、数カ所を除いてなんとかがんばる予定です(←既に数箇所諦めています (^^;)

なお、現在開発中の画面の一部を公開します:
2019091601


2019091602


このカレンダー機能は実は現行版にも含まれていますが「隠し機能」的な位置づけでした。新バージョンではメニューから表示できるようにします:
2019091603


ゲーム要素にも新しい画面を取り入れる予定です。これは「アタック25」モードのページ:
2019091604



次に「ハイブリッドクラウド化」。まず現行版は私の自宅にある ThinkPad 内にアプリケーションサーバーとデータベースサーバーをインストールして動いています。要は(一部の機能は外部APIを使っていますが)ほとんどを自宅内のリソースで提供しています。クラウド時代をある意味で逆行しているものです(ただ個人開発者としては今でもこの形のアドバンテージはあると思っています)。これを一部パブリッククラウドに移して(一部は自宅に残して)コンテナ化するようなハイブリッドシステムを構築する方向で進めています。詳しいシステム構成は後述します。

最後の「ブロックチェーン対応」、これは改ざんが困難な仕組みである「ブロックチェーン」の技術を使い、利用者がマンホールマップにアップロードしたデータが正しいものである(改ざんされていないものである)ことを保証する仕組みを提供するつもりです。


【新バージョンのシステム構成(予定)】
上記の要素を取り入れ、マンホールマップのシステム構成は現行のこの形から、
2019091501


最終的にはこのような形に変更する予定です。今まで以上に公私混同具合が大きくなります(苦笑):
2019091502
(↑ブロックチェーン部分のネットワーク構成は面倒なのでかなり省略)


なお、データベースサーバーのみ独立して自宅サーバーで稼働し続ける形になりますが、これもいずれはパブリッククラウド化を考えています(当面自宅に残す理由はコストパフォーマンスの問題です。クラウドのデータベースサービスは高い・・)。


リリースを優先する意志もあるので、新バージョン公開段階でどこまで実装できているかはまだ不確定要素もありますが、この最終形を目指して開発を進めていくつもりです。なお UI はまだ変更の可能性が高いのですが、ハイブリッドクラウド化とブロックチェーン対応は試験的にはもう動いていて、技術的な目処はついています。


【新バージョンの公開予定】
新バージョンは現時点では令和元年11月2日に開催予定の「マンホールナイト11」にてお披露目予定です。可能であれば(そして大きなトラブルがなければ)この日に前後する形でシステム公開するつもりでいます。




 

このページのトップヘ