CRMチームのエンジニアリーダー(仮称)の倉嶋です。
(仮称)としているのは、今年度からできた役職で名称がまだ固まってないからです。
チームの組織課題について責任を負っています。

さて。自チームの技術展望について、過去・現在を元に書きます。
免責事項として、社全体の展望ではありません。自チームに閉じたものです。

はじめに

こんにちは清水です!
この記事は、Xonsh Advent Calendar 2018 – Qiitaの6日目の記事です。

こんにちは。クラシマです。
ハンズラボ Advent Calendar 2017 4日目の記事です。

もう随分前になりますが、井上がGolang製のDynamoDB用のCLIを探していたことがありました。

ネットストアのセールに向けて行った負荷対策について/ハンズアラボエンジニアブログ

結局見つからなかったのでNode.jsで井上本人が書き、現在もECサイトの本番環境で使っています。
↓それがこちらのbikkeです。
https://github.com/inouet/bikke

10月末くらいから趣味プロジェクトでGolangを書いていたのですが、
井上の記事を思い出したのでDynamoDB用のCLIを書くことにしました。
できあがったものが↓これです。
https://github.com/watarukura/gody

自分でCLIのツールを書くのは初めてなので三歩進んで二歩下がりながら進めています。
個人的にJSONを手で書くのが苦痛なので、JSONをオプションに使わない、というのがコンセプトです。
まだlist/get/query/scanしかできないので、put/update/deleteができるようになったら本番環境で使えないか検証したいところです。
put/updateのオプションをどうするか、今も悩んでいます。
テストもあまり書けてないですし・・・。
趣味プロジェクトから業務プロジェクトに反映するにはもう少し時間がかかりそうです。

Golang、いいですね！
低レイヤーの知識がないと速いプログラムが書けない、というところも魅力です。
日頃はPHPを書いていて、ポインタやバッファを気にすることはなくて、この辺りの扱いはさっぱりです。
今のところも並行処理的な機能をほぼ使ってないので、速くなる余地が随分残っている気がします。
あとは、JSONの扱いが楽なのがモダンな言語という感じがします。
弊社、ユニケージ開発により大量のBashスクリプトが稼働していますが、JSONの扱いは特に困るところです。
DynamoDBをデータストアの1st Choiceにするプロジェクトはそれなりにあるので、
そこでJSONを経由せずにDynamoDBを扱えるようになると、楽ができる部分は結構増えます。
ECサイト以外でも、ハンズラボ全体で使えるツールになるといいなぁと夢想しています。

AWS LambdaのGolangサポートも発表されましたし、今後ますますGolangを使うシーンが増えそうです。
折よく、開発に使っていたGoLandも販売開始になりました。
PHPStormユーザがGolangを書くならGoLandで決まりですね！

ハンズラボ Advent Calendar 2017 の5日目は、青木さんです。

Golangの学習には以下の書籍とサイトに大変お世話になりました。
この場を借りてお礼申し上げます。

• スターティングGo言語
  通勤路で読むのにちょうどよい内容でした。コラムでGolangのポインタについて「C言語との互換性のためにある」という見解で、使わなくても書けそうだなーと気が楽になりました。
• Treasure 2017 の研修資料は Go を学ぶのに最高だった
  GASでSlackBotを書く趣味プロジェクトが一段落して次を探していたときに、こちらの記事を読んでGolangの学習を始めました。
• Go入門　Treasure2017版
  A Tour of Goに挫折していたのでこのスライドを見て再挑戦でした。ajito.fmに出てるsuzukenさんだ！と気づいたのはちょっと後になってからです。
• Go言語でAWSのサービスを使ってみる ~SQS・DynamoDBを試す~
  aws-sdk-go、扱いが辛そうで躊躇していたところ、こちらの記事記載のaws-sdk-go-wrapperをみてwrapper-wrapperなら書けそう！と思えました。
• GoでAWS SDKを叩くCLIツールを作ってリリースするまでの流れ(aws-sdk-go+cobra+viper+gox+ghr)
  flagパッケージだけではサブコマンドのあるCLIを作るのは辛そうだったので、こちらの記事を読んでCLIフレームワークにcobraを使いました。
• Golangのコマンドライブラリcobraを使って少しうまく実装する
  テスト書いてないまま「テスト駆動開発」を読んでいて不安が増してきたため、テストの書き方を参考にさせていただきました。

※ アイキャッチのGopherくんの原著作者はRenée Frenchさんです。

　謎テクノロジー第4回目です。多分これで最後ですね。

季刊どころではなく年報レベルになりました。モチベモチベ。

　前回は、ユニケージの具体例を、仮想アプリケーションをもとに説明しました。
今回は、

• ぼくのかんがえたさいきょうのくらうどあーきてくちゃ
• クラシックユニケージのpros/cons

について議論します。

　またクソ長くなってしまったのですが、想定読者層はそれでも読んで下さるようなエンスーな方々なので、
特に気にせず参ります。

目次

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

  • ぼくのかんがえたさいきょうのくらうどあーきてくちゃの特徴
    • Elastic Beanstalk SQS worker や EMR でやるようなところを ユニケージ で構築
    • とりあえず集計検索系を RedShift に
  • くらうどあーきてくちゃまとめ

• クラシックユニケージのpros/cons

  • pros
  • cons
• 連載のまとめ

続きを読む ハンズラボが採用しているユニケージという謎テクノロジーについて 第4回

謎テクノロジー第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の方向の一方向のみ
ということです。

ここまでのまとめ

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

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

理解のための具体例

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

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

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

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

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

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

このアプリケーションで登場するデータを以下に列挙します。
簡単のため、正規化は第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フルマネージドなメタユニケージではそれがどのように変わるか
について議論したいと考えています。