謎テクノロジー第3回目です。
このままでは季刊な連載になってしまうので、ちょっと真面目にやります。
折角 AWS Summit でこれまでを読んで下さった方が増えたみたいなので、
重い腰を上げます。
実際には今は腰ではなく、肩と二の腕がひどいことになっています。
Day 1 の池澤あやかさんの好きな言語をスマホ振って応援アプリのせいだ……ｗ
このアプリについては Codezine 様の以下の連載をご覧下さい。

池澤あやかさんにお願い！ AWS Summit Tokyo 2015「デベロッパーカンファレンス」を盛り上がるアプリを一緒につくってください！
私はC#推しで2台のスマホで死ぬほど振った結果死にました。

さておき。

前回までで、ユニケージとはそもそも何であるかという点と、ユニケージのごく初歩的な処理の具体例について書きました。
今回は、単体のスクリプト内のデータフローではなく、 もう少し広くシステム内で、ユニケージのデータがどのように流れていくか、について記述します。

目次

• データフロー
  • データのレベル
  • ここまでのまとめ
  • 理解のための具体例
• テキストファイル + DSLコマンドのユニケージを超えて
  • 最近の流れ
  • データのレベル概念を汎化する
  • ぼくのかんがえたさいきょうのくらうどあーきてくちゃ
• 次回以降の内容

データフロー

データのレベル

ユニケージは半角スペース区切りのテキストファイルとしてファイルを保存することを、これまでに述べました。
しかし、RDBMSのようにDDLで予め宣言されるようなスキーマもインデックスもビューもキー制約も無く、
実務レベルでどのようにテキストファイル内のデータを駆使しているかについては、あまりイメージが湧かないと思います。
ここでは、ユニケージにおけるデータのレベル概念を説明し、
実際の系においてどのようにデータが処理されていくかが理解してもらえることを目指します。

ユニケージにおいては、系に存在するデータは、レベル1から5
の5階層のいずれかに属します。
この5階層データを順に説明します。

以下、
ユニケージ形式 : 半角スペース区切りのテキストファイル(UTF-8)
と定義します。

レベル1

• アプリケーションにより submit されたデータ(WebアプリやAPI等)や、ユニケージで構築されたシステム外から取得したデータ。

• JSON, XML, CSV, および画像ファイルや Excelファイルなどの blob をはじめ、任意の形式を想定する。

• 全てのデータを永続的にストックし、決して削除してはならない。

レベル2

• レベル1データをユニケージ形式に変換したもの。

• 変換処理は各々のシステムに応じた頻度のバッチ処理で行われる。

  • 多くは cron にて分単位から日単位で登録された、レベル2データ作成バッチにより行われる。
  • Excel データであれば、Apache POI をラップしたコマンドにより変換をする。
  • さすがに画像はテキストへの変換はしないが、リサイズやサムネイル相当画像生成は必要ならば実施する。

• 基本的には細かいロジックを挟まずに1ファイルずつ対応するように変換する。

  • ただし階層構造のあるJSONやXMLのようなデータは、ユニケージ形式といえどキー設計された表形式データであるのは RDBMS と全く同じなので、プライマリキー相当のフィールドにより、1ファイルだが複数レコードとすることもある。

• データを削除しても原理的にはレベル1から復元可能だが、基本的には削除しない。

レベル3

• レベル2データのテーブル群から、必要なデータを結合して整理されたデータ。

  • 5W1H で整理したデータにせよ、といわれる。

• 変換処理についてはレベル3と同様、各レベル3テーブルごとの頻度で個別の生成バッチが実行される。

• 業務系の基盤になるデータで、[日月年] で集計することになるようなデータをもとにして設計する。

• ユニケージの通常利用でもっとも重要なデータ階層で、このデータは別のシステムからの参照も想定する。

• データを削除しても原理的にはレベル2から復元可能だが、基本的には削除しない。

レベル4

• レベル3データ群をもとに、個々のWebアプリケーションからの使用を想定し作成するデータ。

• RDBMS では、ビューやインデックスに対応する概念といえる。

  • アプリケーションの高速化の為に作成されるため、レベル3を随時参照するならばこのレベルのデータは不要。

• このレベルのデータのみ、完全な破棄とレベル3データからの再生成が許可される。

レベル5

• ユニケージのシステム外にアプリケーションから出力されるデータ

• アプリケーションログ、ユーザがダウンロードした Excel 帳票, ファイル連携する外部システムに送信したファイル、などがある。

また、これらのデータのレベル概念において、重要な原理は、
データの生成フローはレベル1から5の方向の一方向のみ
ということです。

ここまでのまとめ

表にまとめると以下の様になります。

レベル	概要	例	削除
レベル1	入力生データ	submit されたデータ、JSON, XML, CSV	不可
レベル2	生データを素直に変換したデータ		原則不可
レベル3	業務ごとに使いやすいように整理したデータ	商品詳細データ、 日×店別の売上トランザクションやサマリ	あまりしない
レベル4	アプリケーション高速化用データ	画面表示に必要なレベル3を結合・非正規化したデータ、 検索画面用インデックスファイル	可
レベル5	外部出力データ	アプリケーションログ、外部システム連携CSV, ユーザダウンロードExcel帳票(動的)	原則不可

ここまででも、実際にどのようにこれらデータが参照されるのか、
今一つイメージが湧かないかもしれませんので、具体例で考えてみましょう。

理解のための具体例

具体的な小さなアプリケーションを想定して、例を考えます。
以下に仕様を記述します。
特に主語が無い場合、主語はユーザ、とします。

• 商品のマスタ一覧を、検索条件を指定して参照することができる。

• 商品のマスタ一覧のCSV出力を、検索後の一覧画面のUIからダウンロードすることができる。

• 個別の商品のマスタの詳細について、マスタ一覧画面から商品詳細画面に遷移することで、これを参照することができる。

• 個別の商品のマスタの詳細について、参照と同様のフローで商品詳細画面に遷移し、この情報を変更することが出来る。

• 商品詳細画面におけるデータ更新は、POST リクエストにて行い、更新内容をBody にあらかじめ定義されたスキーマのJSON で記述する。

このアプリケーションで登場するデータを以下に列挙します。
簡単のため、正規化は第1正規化のみ行った位のデータが主であると考えて下さい。

データ名	概要	レベル
商品詳細マスタ	商品の詳細データ。 商品名から価格、説明、画像URIなど全てを含む	レベル3
商品一覧	マスタ一覧画面の検索用。 商品詳細マスタから作成。	レベル4
商品検索結果出力	マスタ一覧画面の検索結果のCSV出力	レベル5
商品詳細更新生データ	商品詳細においてユーザが更新操作時にリクエストに含まれる、 JSON形式の1商品詳細の更新データ	レベル1
商品詳細更新データ	商品詳細更新生データをユニケージ形式に変換したデータ。 商品詳細マスタと同一のフィールドと主キー定義を持つ。	レベル2
商品画像	商品画像の実体ファイル	レベル1

以上をもとに、このアプリケーションでデータがどのように参照・更新されるかをまとめると、以下の様になります。

• マスタ一覧の参照時、事前作成済みの商品一覧ファイルを検索条件に基づいて join系コマンド、grep や awk でフィルタすることで、ユーザの求める検索結果を表示させる。

  • レベル4データの参照のみ

• マスタ一覧の参照時、CSV出力のアクションにより、検索結果と同一のフィルタがされた商品検索結果のCSV出力がダウンロードされる。

  • レベル4データからレベル5データを随時作成。

• マスタ一覧から商品詳細画面に遷移して、商品詳細情報を参照する。

  • レベル4データからレベル3データのキーを取得し、これを指定してレベル3を1件取得し、商品詳細画面を構成。

• 商品詳細画面で商品詳細情報を更新する。

  • 画面の状態から商品詳細情報に相当するレベル1データのJSON文字列を作成し、POST する。

• 商品詳細情報更新後、マスタ一覧に更新が反映される。

  • レベル1データの POST 時に、サーバサイドでレベル1データはレベル2 データに変換されて保存される。
  • さらにLV3データ、LV4データと順番にバッチ処理で、タイムラグがありつつも更新される。

• 商品詳細情報更新後、同一画面にて更新が反映される。

  • 前述の更新時のレベル2データとレベル3データを両方参照し、更新日時が最も新しいものを採用し、画面を構成する。
  • ユニケージでは、このような随時更新されすぐに再参照されるデータの整合性担保に関してはいくつかの方法が示されているが、筆者はこれ(関連レベルデータのうちupdate最新日時のデータを採用)が一番わかりやすいと考える。
  • いずれにしても厳密なトランザクションや整合性に関しては、ロック処理を別途実装する必要がある。
  • 同一レコードに対する更新操作が短時間に大量に発生(厳密ではないが、10[req/(sec * record)] 以上を想定)するシステムでは、そのロック処理も限界があるので、そもそもユニケージは向かないと考える。この話は別途。

長くなりましたが、ユニケージのデータフローについて、少し感覚が掴めて頂けたのではないでしょうか。
むしろ筆者はこれを書いていて理解の整理が進みましたｗ

テキストファイル + DSLコマンドのユニケージを超えて

最近の流れ

最近弊社も、長谷川がJavaScriptで全部やるんやーの大号令を出したり、
そもそもAWSマネージドサービスを中心にするということで、
これまでのユニケージ(筆者はクラシックなユニケージと呼んでいます)では
そもそもにっちもさっちもいかないのでは、と考えています。
事実、ユニケージはオンプレミス+ホットスタンバイ+ローカルでのファイル保持がもともとのアーキテクチャなので、
複数のアプリケーションサーバで正しく同時に稼働させるのには、
かなりのつらみがあることは察して頂けると思います。

データのレベル概念を汎化する

ですが、前述の例で出したようなデータのレベルの考え方を、
マネージドサービスのデータストアにテーブルやキー単位で与え、キューなどを組み合わせることで、
ユニケージと同等のデータフローと整合性を持って、完全にスケールするシステムが作れるのではないかと考えています。
これをクラシックなユニケージから大きく離れず、
一定のレベルでシンプルに実現したのが、
弊社田部井を中心として実現した、S3をデータストアとして、
クラシックなユニケージで実現したポイントソリューションシステムでしょう。
S3をDB利用 ショッピングセンター向けポイントシステム概要
第三者の視点での評価として、このアーキテクチャは
AWS様のAPN Architecture of the Year 2014
にて、クラスメソッド様の紅白歌合戦事例に次ぐ評価を頂いています。
AWS Partner SA ブログ: APN Architecture of the Year 2014のご報告

ぼくのかんがえたさいきょうのくらうどあーきてくちゃ

ユニケージのデータ整合性やロックのつらみに関しては、
他のNoSQLなアーキテクチャにおけるそれと類似している部分がかなりあるので、
ユニケージのデータフローに関してメタにとらえて再構築することで、
他のNoSQL環境において解決できる問題も出てくるのでは無いかと考えています。

AWSのサービスでいうと、本記事の言及範囲では、
SQS, Kinesis, EMR, RedShift, S3, Lambda, CloudSearch, DynamoDB & DynamoDB Stream(はよ)
あたりを組み合わせて使う事で、クラシックユニケージではないがその思想を借りた、
整合性は数秒単位でそれなりだが、完全にスケールして集計もできる、
NoSQL中心システムが構築可能ではないかと考えています。

これに関してはだいぶ前から考えていたのですが、
AWS 公式のDynamoDB Deep Dive スライドの最後から2枚目の、DynamoDBリファレンスアーキテクチャでほぼ私の言いたいことは示されてしまっていたり、
Deep Dive: Amazon DynamoDB
Cassandra を中心としたアーキテクチャとも類似点があり、データストアの特性が類似していればアーキテクチャも類似するものなのかな、と思いました。
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ～Apache Cassandra編～
ワークスアプリケーションズ様のRDBMSを使用しないERPである、
HUEの設計事例のお話を伺いましたが、これも抱える問題や解決方法について類似しているように思えました。
Sessions / JJUG CCC 2015 Spring（4月11日開催）AB-1 社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話 | 日本Javaユーザーグループ

Cassandra などでも絶対スケールするシステムは作れると思うのですが、
なんだかんだ強いDBAの様な人や、Cassandra はじめミドルのお守りが高いレベルで出来る人、
アプリケーション開発者の大きな負担、
もしくはそれを和らげるDTOなどの整備が出来る優秀なエンジニアを一定量確保することが必要そうに思えることを考慮すると、
AWSがある程度使えて、普通のソフトウェア設計が普通にちゃんとできて、
普通に実装もちゃんとできる、というレベルの、
普通にいるちょっと優秀なレベルのアプリケーションエンジニアが数人いれば、
この絶対スケールするシステム、少し楽観的に見てますが、ミドルを自ら管理するコストを抱えずに、なんとか作れそうな気がしてきます。
# 私が作るとは言っていない(ひどい)

次回以降の内容

今回単語レベルでばーっと書いた、
DynamoDBリファレンスアーキテクチャ の fork のようなメタユニケージスケールしまくるアーキテクチャの図をもう少し熟考して作ってきます。

また、上記と絡めて、
– クラシックユニケージのpros/cons
– AWSフルマネージドなメタユニケージではそれがどのように変わるか
について議論したいと考えています。