UD Day 12 アーキテクチャーの検討7(DBのノード分散)

仮にブラウザを多数の人が利用する場合、バックエンドのシステムは非常にスケーラブルである必要があります。なぜなら、ブラウザを使うことはそれだけ日常的なものだからです。Webサーバやアプリサーバについては、ノードを分散させることは難しくはありませんが、最も問題になるのは、DBサーバーです。

スケールアウトを前提とする際の構成としては、以下の方法が考えられます。
・マスタースレーブ構成(スレーブは読み取りのみ)
・グループレプリケーション(1つ、または全てのノードで読み書きが可能)
・パーティショニング(PKごとにデータを分散配置する)
・テーブル毎に配置するノードを変える(アクセスパターンに応じて分散。コメントはノードA、ソーシャルはノードB)

上記を踏まえて、実際のプロダクト例を見ていきます。特に、ここでは、初期にどの程度のノード数が必要かという点に着目したいと思います(スモールスタートが望ましいと考えたため)。

a. MySQL:グループレプリケーション+マスタースレーブ構成の組み合わせによる分散

MySQL グループレプリケーション+マスタースレーブ

グループレプリケーションのグループもしくはマスタースレーブの組み合わせを一つのリソースグループとして考えます。データ的には、プライマリーキーのはじめの値が何であるかによって、どのリソースグループに接続するかという判断を行います。これを実現するには、クエリーを設計した上で、テーブルの物理設計に落とすという順番が必要となります。(パーティショニング=データがノードで分散するものについては、基本的にこの方法になると思います。)
これまでのクエリーとは条件が全くことなるようなクエリーを新規に作る必要性が生じた場合には、テーブルを新しく追加する必要があります。
ノード数が多くなることと、管理の手間などもあり、少し大変な方法かもしれません。

b. MySQL:MySQLクラスターによる分散
MySQLクラスターはミッションクリティカルなサービスでも本番利用がされている製品です。ノードは、SQLノード、データノード、管理ノードに分かれ、SQLノードがインタフェースとなって、データを取得しに行くという仕組みです。管理ノードはクラスターの管理等の役割があります。データノードを増やすことで容易にスケールアウトさせることができます。標準でインメモリーでありながら、永続性が保証されるなど、最強ソリューションかもしれません・・・

MySQLクラスターノード変遷例

最小構成でもそこそこのノード数が必要となることがわかります。
参考)MySQL Clusterの特徴とアーキテクチャー (構成イメージもあります)

c. MongoDB
アプリノードで動かすmongosルータからmongodサーバーのデータを見に行きます。これらに加えて、設定サーバーが必要(mongodの一つに同居)となります。
mongodサーバーをシャーディングする形(データをシャードごとに分割して行く)になります。

MongoDBノード変遷例

単体はさすがに採用し難いですが、初期にスモールスタートすることも可能な構成と言えそうです。候補の一つとして考えに入れました。
参考)MongoDBの高可用性構成

d. HBase
マスターノード(Master)、スレーブノード(Region)の二つがあります。これらに加えて運用管理用のノードが必要となり、以上の3種類から構成されます。データはスレーブノードに含まれます。

HBaseノード変遷例

基本的な推奨構成は、8台以上となり、初期の段階でノード数が多くなりそうです。
参考)HBase導入時の検討項目と推奨構成

e. cassandra
管理系のノードは存在しません。ノードが参加して構成するものを輪っかになぞらえて、「リング」とCassandraでは呼びます。このリングに参加するノードは全て平等です。スケールアウト時の処理量は比例します。cassandraはReplication Factor(いくつのノードに同じデータを持つか)を設定でき、これがノード数とともに冗長性にとって重要となります。また、一貫性のレベルをクラスターに設定でき、それは以下の4種類があります。Quorumの選択が良さそうで、この場合、node=3/rf=3が最小の推奨構成(rf=2だと1.5となり、結果1=ONEと同じ)となります。
 ・ Zero(一貫性の保証なし)
 ・ One(1つのみの一貫性を保証)
 ・ Quorum((ノード数+1)/2の数分の一貫性を保証)
 ・ ALL(全ノード数分の一貫性を保証)
 (下に行くほど一貫性が強い)

Cassandraノード変遷例

MongoDBと同じく、初期のノード数という点てハードルが低い事がわかります。
参考)
Apache Cassandraについて
TwitterとDiggがCassandraを選ぶ理由 (Twitterは、現在はCassandraではなく、Cassandraベースの自社開発のDBであると記憶しています)
Cassandraのノード数の最小は3必要なのか?

以上の内容から、ここまでで、MongoDBもしくはCassandraが望ましいと考えました(初期のノード数が少ない)。ここからCassandra => ScyllaDB(CassandraベースのDB)にした理由は別の回で言及できればと思います。(続く)

UD Day 11 アーキテクチャーの検討6(URLをどう保存するか)

UDでは、クライアントサイド(ブラウザ)で閲覧しているページのロードが終了した段階で、URLをキーとしたリクエスト(コメントを取得するためのリクエスト)をバックエンドのシステムに送出します。URL長の最大値は非常に大きいものになるため、このままではデータベースのキーとするには不適切です。
そのため、分散系のDBではよくある手法ですが、キーとしてURLのハッシュ値を用います。

ハッシュ値を用いる際に検討しておきたいのは、どの程度の確率でハッシュ値が同じになるか(衝突するか)です。これは、誕生日のパラドックスと言われます。

誕生日のパラドックス

異なるURLがたまたま同じハッシュ値になってしまうケースです。
数学的には誕生日攻撃と呼ばれるようです(異なる入力値が同一の関数を経て同じ結果になってしまうこと)。
上記リンクによると、衝突がおこなるまでの試行回数の期待値(birthday bound)は、nビットの数字において、2のn/2乗となるようです。

暗号アルゴリズムごとのbirthday bound

いくつかのアルゴリズムでどの程度のbirthday boundの値になるかを示したのが、上記の表になります。MD5の場合で1844京回となります。
世界中のウェブページについて投稿された場合に、どの程度であれば、衝突がなるべく少なくすることができるか。正確な計算はできませんが、この点を類推の上で、ハッシュアルゴリズムを選択しました。参考にしたリンクは、「参考リンク」の「URLのハッシュについての質問」のページです。ここでは、選択対象とそのロジックについては割愛します。

では、次に、これをDBで保存する際には、どういうデータ型を用いればよいでしょうか。Cassandra(ScyllaDB)のケースで以下の2つの方法が考えられます。
a. string型
stringで保存するには、16進数のまま、もしくは16進数をbase64,ascii85などに変換して保存できます。16進数の値をそのまま文字列として保管する場合40byte, base64に変換する場合、平均26.7byteになります(試行結果)。

b. blob型
バイナリーで保存する場合には、blob型を用いることが出来ます。
CQLでinsert、selectする場合にも特段問題なく利用できます。

実際に同じデータでどの程度のサイズの違いがあるかを試してみると、
a: 72,879,839
b: 52,626,907
となりました。データの効率性からすると、後者が良いようです。

以上の考察結果から、UDでは、ハッシュ変換したバイナリーデータをblob型でDBに保管する方法を選択しました。(続く)

参考リンク)
shortURL考察
誕生日のパラドックス
誕生日攻撃
URLのハッシュについての質問
SHA-1を保存する場合の方法、CHAR(40)かBINARY(20)。BINARYで正常な使用ができるのかは確認が必要。
UNHEX, char, binaryについて
PKにする場合は、BINARYは適切か
GUID/UUIDをPKに使う

UD Day 10 アーキテクチャーの検討5(コメントの表示方法)

元々作ろうとしていたものは、ウェブページ上で位置に応じて吹き出し形式のコメントを表示する形式のものです。ゴールから逆算するために、Day1でも示した最終形のイメージを示すと、以下のようなものです。

背景色が白の一番下の描画領域が実際にブラウザが表示するウェブページで、その上には、右端にグレーの細長い領域とその上にアイコン、そして、吹き出しがあります。
具体的に、コメントをウェブページ上に表示するのはどういう方法になるのでしょうか。iOSで実装する場合に検討したものは以下のようなものです。

コメントをどのように表示するかの図解
  • WKWebView … iOSでウェブページを表示するために使うView(実際の画面表示を行っている要素)。内部的に、UIScrollViewを含む。
  • UIScrollView … 表示できる領域よりも表示する対象のコンテンツが大きい場合、スクロールが必要になります。UIScrollViewはスクロールのついてUIViewです
  • BubbleMessage … カスタムのクラスで、BubbleとUILabelから構成されます
  • Bubble … カスタムのクラスで、吹き出しの形をしたView(画面要素)です。
  • UILabel … テキストを含むUIViewです。

当初、UIScrollViewをWKWebViewの上に載せ、さらにその上に、吹き出しを載せ、WKWebViewのUIScrollと同時に動かすという無駄にややこしいやり方で考えていました。そもそも、WKWebViewの表示領域にコメント領域をそのままベタで載せれば、WKWebViewのスクロールで一緒に動かすことができるので、最終的には、こちらのよりシンプルな方式にしました。
そして、吹き出しは、吹き出し(Bubble)形式のクラスとテキストからなります。美しい吹き出しをどのように作成するかは、別の記事で紹介します。他の会社さんではどのように作っているかも知りたいところですが、おそらくそう変わらない実装の仕方だと思います。

以上が、コメントの表示方法を分解したものですが、これらの処理は、リロードやページの遷移ごとに発生します。つまり、このユーザー動作ごとに、コメントデータの取得とコメントの表示処理が行われます。実際にこの処理が行われるタイミングは、ブラウザの処理サイクルと関係しており、ブラウザのページ表示処理の終了時(webView:didFinish)のタイミングで呼んでいます。(続く)

UD Day 9 アーキテクチャーの検討4(web socket)

当初は、リアルタイムかつ双方向のコメントの受信を考えていました。その際にsocket.io というフレームワークがサーバーサイドの技術として有力で、モバイル側にもiOS、Androidともにweb socketの技術があったので、これを検討していました。ただ、実際の実装イメージがわかりにくいので、検討の段階で、どういう形になるかについて調査しました。具体的にリアルタイムなやり取りをどのように行うかを図解すると以下のようになります(一例です)。

iPhone〜サーバー間のWeb Socket通信

モバイル、サーバー間のやり取りをフロー化すると以下のようになります(一例です)。

iPhone〜サーバー(アプリ&DB)間のWeb Socket通信のフロー

クライアント(モバイル端末)からサーバーに接続した後は、emitによって情報を相手方に送信、onで相手からの情報を受信(常時)という形になります。
初期の対象としては、通常のAPIに比べてハードルも高かったため、結局は採用しませんでした。最初からリアルタイム性を売りにしたいようなアプリ・システムについては、web socketなライブラリーを採用するメリットはあると思います。
ちなみに、Firebaseを使うのもありです。サーバー系全般についてFirebaseをはなから対象にするというのもありですね。弊社でこのシステムを作る場合は、とにかく、スケーラビリティが重要だったので、自前でスケールするものを作ることにこだわりました。(続く)

参考)
・iPhoneの場合は、socket.io、Socket Rocket
・Androidの場合は、android-websockets
をライブラリーの候補として考えていました。

参考リンク)
チャットなどリアルタイム更新が必要なスマフォアプリの構成について考えてみた

UD Day 8 アーキテクチャーの検討3(kubernetes)

インフラのコード化(IaaS)を行うにあたって、VM上で構成管理ツールを選択するか、kubernetes(k8s)を採用するかという2つの選択肢が考えられました。どちらにすべきかを多面的な視点で行い、結果、VMを選択しました。
ただし、GKE(Googleのk8s環境)については、Googleの運用上のノウハウを結集して作られているのがk8sである、GKE自体もGCPの他のサービス(Loggingなど)との連携が良い、等のことから、採用するメリットは高いと思いました。
前回にも記載しましたが、最終的な判断は、DBの部分によっていて、DBを結局VMベースで構築するのであれば、2つのスキル、2種類のファイル郡が必要になり、無駄に感じました。そのため、VMベースを選択しました。

DB系のサービスについてもパフォーマンス上の懸念がなければ、k8sは良い選択肢です。ローカルも全てdockerベースにできれば、統一的な管理ができて、良いですね。

構成管理ツールについても、別で検討しています。どこかで触れることができればと思います。

参考)
GKE & k8s アーキテクチャ
Redis + PHP on GKE
WordPress + Mysql on GKE
Mongo DB/StatefulSet on GKE

UD Day 7 アーキテクチャーの検討2(クラウド・サービス)

Day6に引き続き、アーキテクチャーの検討を行います。アーキテクチャーの検討と言いつつ、主たる内容はコストの比較です。想定するスペックに対して、どの程度のコストかを比較しています。
最終的には、GCPを採用しています。その理由は、Live Migration、自動割引(個人的にReserved Instanceの考え方が好きではない)、詳細なスペックを見た際のコストパフォーマンスからの判断です(当時の判断)。既に優位なポジションを気づいているAWSに対して他のパーティが価格を含めた別の面で価値を訴求するのは当然なので、その面で考えても、他のクラウドパーティも検討することは合理的だと思います。
主に金融系などの基準が厳しい業界であれば、業界基準やISOへの準拠状況なども参考にすべきかと思います。

実際の比較表は以下の通りです。いずれも東京リージョンで、当時のドル円レートとして1ドル=110円で計算しています。

GCPにおけるコスト比較
AWS、Azureのコスト

大まかにGCPのGCE、AWSのEC2、AzureのVMを比較すると大凡同等スペックではGCEが優位性があると判断しました(上記のGCEの表にはLoad Balancerのコスト(=負荷分散の項目)を含めているのでこの分は割り引く必要があります)。厳密には、更にGCE以外のサービスについても比較が必要ですが、ここでは割愛しています。尚、クラウドパーティ以外の第三者がサービスを提供している場合は、割引がある場合があるので、この限りではありません。

次にGCPの中でどういうサービスを使うかを検討する場合、以下のような点がポイントになると思います。
 a. OS以上をすべて自社で管理する(GCE)vs極力アプリ層に注力する(GAE)
 b. 想定するサービスレベルを満たす可用性か(何%以上の稼働率を想定するか)
 c. Docker/Kubernetes(GKE)を採用するか(aとも関連)

aについては、後者の方が高くなります。コスト比較の結果、GCEにしました(その分、構築コストが必要になります)。

bについては、最新の情報を参照すると、各サービスごとの違いはあまりないようです。全体の可用性を更に考える場合には、同一のインスタンスを複数稼働させる、別Zoneにそれぞれ複数インスタンスを稼働させるなどのことを考える必要があります。
c.f.)稼働率を考える場合の参考値
  ・95%・・・・・・・18.3日
  ・99%・・・・・・・87.6時間
  ・99.9%・・・・・・8.76時間
  ・99.99%・・・・・ 52.6分
  ・99.999%・・・・・5.26分

cについては、DBサーバーを考える場合、当時の時点(2017)では、Dockerの選択は効率性の観点から採用を考えられず(*)、組むとしたら、APサーバーをGKE、DBサーバーをGCEという方式でした。構成ファイルを作り、管理していく場合に、それぞれのスキルが必要であり、2種類のファイル群を管理していくことになり、効率的ではありません。このような、観点から、GKEは様々な点で魅力があったものの、採用しませんでした。
いずれにせよ、Dockerの利用が強い分野はStateless=アプリ系な分野であったので、Stateful=DB系については、無駄なオーバーヘッドがないかを調査しておく必要があると思います。

(*)…後々の工程でも出てくるかもしれませんが、DBサーバーとしては、最終的にScyllaDBを採用しましたが、当時の時点では、Docker上で構築した場合のパフォーマンスが悪いという報告がありました。Cassandra系のモノの本にもそのような記載があります。現在見てみると、Docker HubにScyllaの公式のイメージがあるので、これを試してみるのはありだと思います。

参考リンク)
GCEのSLA

UD Day 6 アーキテクチャーの検討1

システムで用いる技術要素を検討します。ここではマネージメント用ツールなどは対象とせず、別の文書で管理しました(マネージメント計画書に含める)。大まかにモバイル、サーバー、開発環境の3つについて整理しました。
後々に登場する構成(デプロイメントモデル等)にも影響するため、ここで調査した各要素技術に関する情報を随時アップデートして開発期間中まで管理しました。調べた情報をまとめておくことは後で振り返り、参考にできることが多いので、有用だと思います。

1.モバイル
モバイルで主に検討したものは以下の通りです。
・Swift:iPhone開発用の言語
・Java:Android開発用の言語
・SQLite:モバイル用のローカルDB(履歴等のローカルで完結する情報を保存する)
・FB/Twitterのログイン用モジュール
・socket.io:Web Socket通信
・CocoaPod:iOS開発の外部ライブラリー管理

ここで議論がありそうなのは、せいぜいローカルのDBに何を採用するかとWeb Socketが必要かという点ぐらいだと思います。DBに関しては、他にも有力なものがありますが、要件としては、SQLiteで満たすため、SQLiteを採用しています。また、Web Socketに関しては、当初、投稿された際にリアルタムにコメントが更新される機能を想定して、検討しました。結果的には不採用としました。初期に実装する対象としては過分であろうと思ったためです。

2.サーバー
・EC2:AmazonのEC2(ウェブ/アプリサーバー用)及びEBS(ストレージ部分)
・Aurora:AmazonのAurora。Google Spannerも良さげだが、価格が高い。水平にスケールする方法(シャーディングとか)も検討が必要。パフォーマンスが出にくい場合には、Redisも検討すべき
・S3:バックアップデータ等を保管するストレージとして利用する
・Docker:必要に応じて検討。本番システムでは用いない方が良いか?管理系などで使えれば程度。
・ELB or nginx:Load Balancer。nginxもしくは、ELBにて行う。
・nginx:ウェブサーバーとして使用する(静的ファイルはnginxに置く。もしくは、S3の利用検討)
・uWSGI:Python用のアプリサーバー(webサーバーとアプリをつなぐインターフェース)
・Django:Pythonベースのウェブフレームワーク
・Django REST framework:REST APIを実現するウェブフレームワーク。コメント部分はiOSのアプリからRESTベースのwebリクエストを出し、jsonを取得するイメージを想定。
・Socket.io / node.js:Web Socketを実現するための技術として、Socket.ioを活用する。Office.comでも利用されている。大規模サイト向けはOKと判断する。
・gin / GOLANG:GOLANGのweb frameworkであるGIN GONICのこと。Python, node.jsよりもGOLANGはパフォーマンスにすぐれる。数あるweb frameworkの中では、GINまたはECHOが有力と考える。
・Zabbix or Prometheus or Stackdriver:監視ツール。管理サーバーに入れるイメージで検討。インフラ部分だけはCloudWatchでやるか?
・Fabric or Spinnaker:デプロイツール。アプリリリースを自動化する。管理サーバーに入れるイメージで検討。
・Jenkins:CIツール。前項のFabricと連携して使うと、サーバーへのデプロイまで自動化できそう。
・Ansible or GCP Deployment Manager:構成管理ツール。複数台のサーバーを利用するので、大規模な対応ができるようにしておく。
・gitlab or git:バージョン管理システム。いづれもパブリックなサービス。
・Compute Engine:ライブマイグレーションしながら管理するようなので、計画停止がない。その点がEC2より優れているか。コストもデフォルトで安い(Reserved Instanceみたいなややこしさがない)。
・Datastore:フルマネージド且つスケーラブル、高レスポンスレートなNoSQL DB。計画停止無し。基本的にはBigtable+特有の機能の模様。ただし、超大規模になった時のコスト比較を要する(料金の計算の仕方がBigtableとは異なる)
・Bigtable:フルマネージド且つスケーラブル、高レスポンスレートなNoSQL DB。HBaseはBigtableを目指して作られているが、Googleの資料によると、Bigtableの方が圧倒的にパフォーマンスがよさそう。
・Cloud Load Balancing:Load Balancer。自動スケール、大量リクエストを捌ける。Websocketへの対応をデフォルトでしており、ELBよりも優位か。
・App Engine:単純にコードの実行のみをするノード。GCEのようにOS層の管理などは必要としない。
・GKE(Kubernetes):Dockerのようなコンテナベースでの管理。ノード自体はGCEを使うので、コスト的にはGCE+α程度で住む。インフラをコード化する観点ではいい選択となり得る。

主たるものは以上ですが、これ以外にも各プロダクト領域ごとで多数の要素技術を検討しました。
最も重要視したのは、コスト(それ故のパフォーマンス性)です
例1)クラウドプロバイダー:AWSとGCPのどちらを採用するかですが、検討時点の内容を鑑みると、コストパフォーマンス的にGCPの方が良いと判断しました。例としてネットワークですが、同程度のインスタンスでGCPのほうがスペック上、良かったです(現在の情報については、存じないことも明記しておきます)。
例2)ウェブフレームワーク:ウェブフレームワークの世界には非常に多数のものがありますが、この選定についてもパフォーマンスベースで選択しました。言語及びそのフレームワークで総合的にパフォーマンス性に優れたものという判断です。結果的に、goベースのgin-gonicを採用しました。また、ここについては、他にgithub上のstar数も考慮に入れました。多いものはドキュメントや情報もよりある可能性が高いという考えからです(この法則に当てはまらないものもあるようですが)。
例3)監視ツール:監視用のソフトウェアも多数ありますが、まずはインスタンスが必要か、クラウドの機能を採用するかという二択になると思います。初期の時点では監視要件的にGCPの監視ツールであるStackdriverでも要件を満たすと思い、こちらを採用しました。より細かい要件を満たす必要がある場合には、Prometheusなどが良いだろうなと思います。
一番最後に、いくつかの参考としたリンクを添付します。

3.開発環境(PC)
・OS X:XCODE, Android Studioの併用ができることを前提にmacとする。
・XCODE:iPhoneアプリの開発
・Android Studio:Androidアプリの開発
・SKETCH:UIデザイン用ツール。使用を検討しても良いというレベル。
・photoshop => illustrator:イメージ作成 => ロゴ作成には、Vector方式のIllustratorの方が良い(様々なサイズに書き出すことを想定して)
・VirtualBOX:ローカル環境の仮想化用
・Docker:サーバーイメージをDockerで動かす。
・CocoaPods:SQLiteなどのライブラリー導入・管理用

開発環境に関しては、Dockerでもローカルにサーバー環境を立てましたが、それ以外にローカルに直接、httpサーバー+DB環境を立てました。主には、後者で開発を進めました。

4.参考リンク
Amazonの構成ガイド
サーバー/インフラ構築徹底入門
大規模サービス技術入門
Cassandra / Hbase
Cassandra説明
Bigtable
Bigtable
Datastore
GCP/AWS比較(運用フェーズ)
GCP/AWS比較
GCP RA
Carthageの使い方
GAEはいけてるか
LINE redis+hbase例
LINE hbase例
hbase構成例(具体的)
FB hbase例
FB hbase例2 構成とか参考になる
FB memcached(Cacheとして)
GCP: Delopyment Manager
Spinnaker(デプロイ自動化)
GKEとは(一番わかりやすく)
GKE構成例(AbemaTV)
Cassandra vs mongo db
Cassandraの特徴を示す記事

以上、今回は、主に検討した要素技術とその検討内容の概要について記載しましたが、別の回で、それぞれの要素技術の検討内容の詳細を記載する予定です。まずは、ご紹介まで(続く)。


UD Day 5 UI検討

Day4のロバストネスモデルに引き続いて、UIのイメージを検討しました。要件定義段階での仮のもの(たたき台)で、これをベースに設計、実装フェーズでブラッシュアップされていきます。UIのツールとしては、Sketchなどが有名だと思いますが、我々の場合はExcelで作成しました。生産性が劇的に違うなどの理由がなければ、ツールにこだわるのは特に実益はないと考えています。
UI検討における成果物は、実際のイメージ図と画面構成要素とその仕様になります。後者は、アイコン、ロゴ、ツールバー、スライダー、吹き出し等々の画面構成要素に対して、フォント、色、実際の形状を仕様化しました。画面構成要素に関しては、以上の概要にとどめ、詳細は割愛します。

上記は概要的なイメージ図になり、通常のブラウザ表示に加えて、コメントの表示機能部分が含まれています。コメント表示を行うボタン(この段階では右上、またはツールバーの真ん中)を押すと、位置に応じて、ユーザーのコメントが表示されています。色が赤や白があるのは、そのコメントへの評価に応じて、色味を変えるためのものです。赤であればより好評価なコメントということになります。

さらにUIのイメージを検討するにあたっては、メインの機能であるコメント機能について、画面遷移を検討しました。通常のブラウザ部分については、特別な仕様はないので、不要と判断し、割愛しています。

コメント機能の遷移1
コメント機能の遷移2
  1. コメントボタンをタップ:スライダー、アイコン、吹き出しが表示される
  2. 吹き出しをドラッグする:吹き出しがドラッグの終了位置に移動する
  3. いいねボタンをタップ:いいねが一つ加算される
  4. スライダーの任意の位置をタップ:コメント作成画面が表示される
  5. コメントを作成し、コメントボタンをタップ:コメントが追加される
  6. アイコンをタップする:コメントに対しての返信があれば、それを表示する
  7. コメントボタンを再びタップ:コメントがすべて非表示に鳴る

結果的には、実際に実装したものは上記の仕様とは少し異なります。設計、実装などを経て、より作成すべきものが明確になっていった結果の差異です。

実際のUIの案(一部)

実際に画面構成要素別にUIのイメージとして作成したものが上記になります。概要イメージでは、コメントの表示非表示を行うボタンは右上でしたが、ここではツールバーの真ん中にしています。ちなみに、ツールバーは、左から、戻る・進む・コメントの表示非表示・タブ切り替え・その他になります(その他には複数のメニューが表示されます。例えばブックマークなどです)

我々の場合は、この段階で実際のボタン用アイコンの作成などはしませんでしたが、ブレがなければ、この段階で実際に実装時に使うものを作っておくのは良いかもしれません(続く)

UD Day 4 ロバストネスモデル

ロバストネスモデルは、バウンダリ(画面)、コントロール(アクション)、エンティティ(モデル=データ)からなる設計です。ユースケースやその詳細化したシナリオをベースとして、上記の単位でどういうものが必要か、という点を明確にするための分析ツールです。ロバストネスモデルによって、MVCなどのモデルに反映させるための要件を明確にすることができます。。
ロバストネスモデルでは、上記のそれぞれを以下のように表します。

ロバストネスモデル 種類

上記が実際に作成したロバストネスモデルの図になります。バウンダリーは、各画面やUIの要素を示し、コントロールは、画面を通じて行われた操作によって実際にモバイル端末、その先のサーバーにおいて行われる動作、エンティティは、その動作において操作する対象のデータ(モデル)になります。
例えば、目玉の機能のページに対してのコメント表示で説明すると、コメント表示はスライダーとその上に表示されるユーザーアイコン及び吹き出しコメントからなっており、まずはじめにこのコメント関連の情報を取得し、描画します。ですので、スライダー(コメントなどを含めた)がバウンダリー、コメント描画がコントロールになります。この場合の対象データはコメント情報(と厳密にはユーザー情報)になります。

バウンダリー、コントロール、エンティティに分けて考えることによって、実際に作るべき対象がより明確になったことがわかると思います。言葉通り当たり前のことですが、ビジネス上の要件をより明確にしていくことが要件定義なので、曖昧さを残さずに、作るべき対象を明確にできている状態であることがその本質です。ユースケースモデル、ロバストネスモデルを通して、少しづつ作るべきものが見えてきた気がいたします。(続く)

UD Day 3 ユースケースモデル

ユースケース図は、アクターとそのアクションを定義するものです。ユーザー視点で、要件の全体像を捉えるのに有効な手段です。ユースケースモデルを通した分析によって、要件が明確になり、プロジェクト内での共通認識を取りやすくなるとよく言われます。スコープについての共通認識を早い段階で関連者間(特にユーザー)と合意するのに有効な手段です。

要件定義のはじめの段階で分析しましたが、プロジェクトのスコープが明確に定義されているわけではないので、実装が今回ではない可能性があるものも含めて、モデルに落とし込みました。
今回は、ブラウザとバックエンドのシステムが対象ですが、ユーザー視点でいうと、通常のブラウザの機能部分とページに対してのコメントを行う機能部分に分かれます。

後者のコメント機能については、ユーザーの視点ではシンプルで、コメントを見る、または書くことです。コメントを見る場合ですが、今回想定しているUIは、表示画面の右側面上にスライダーを表示し、その上にコメントしているユーザーのアイコン、そしてそこから実際のコメントの吹き出し、という形式です。ですので、これらについても詳細をブレイクダウンしたアクションを検討します。具体的には、スライダーの表示・非表示、コメントの評価(いいね)、返信、新規のコメントなどになります。つまり、単に見る、書くというのがトップレベルで、それをブレイクダウンしたものがこれらということになります。

以上のような形で検討し、作成したダイアグラムが以下のものです。
a. コメントを見る、書く(トップレベル)
b. aのブレイクダウン
c. a以外のブラウザ標準外の機能
d. 標準的なブラウザ機能

ユースケース図

ユースケースを通して、ユーザーの観点で必要なものの洗い出しが早い段階でできたという意味で、メリットがあったと思います。
上記の分類がそのまま以降で実装した機能の単位とイコールではありませんが、大まかに言って実装する単位がイメージしやすいという点も利点と言えると思います。作成もさほど大変ではないので、要件の明確化をしたい場合に作成してみると良いと思います。
ちなみに、ツールとしては、UMLの作成でそこそこ知られている(?)と思われるStarUMLを使いました。よろしければ、ご参考に!(続く)