AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

12

カテゴリー: ユニケージ

GolangでDynamoDB CLIを書く話


gopherくん

こんにちは。クラシマです。
ハンズラボ 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の学習には以下の書籍とサイトに大変お世話になりました。
この場を借りてお礼申し上げます。

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


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


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

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

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

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

について議論します。

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

目次

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

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

    • pros
    • cons
  • 連載のまとめ

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


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


謎テクノロジー第3回目です。
このままでは季刊な連載になってしまうので、ちょっと真面目にやります。
折角 AWS Summit でこれまでを読んで下さった方が増えたみたいなので、
重い腰を上げます。
実際には今は腰ではなく、肩と二の腕がひどいことになっています。
Day 1 の池澤あやかさんの好きな言語をスマホ振って応援アプリのせいだ……w
このアプリについては 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)] 以上を想定)するシステムでは、そのロック処理も限界があるので、そもそもユニケージは向かないと考える。この話は別途。

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

テキストファイル + 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フルマネージドなメタユニケージではそれがどのように変わるか
について議論したいと考えています。


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


謎テクノロジー第2回目です。
諸事情によりだいぶ時間が空いてしまいました。色々と厳しい。

今回は簡単なサンプルコードを用いて、もう少し突っ込んでユニケージの処理例について解説します。
繰り返しになりますが、この連載での記述は全て筆者の見解であります。と、念押し。
# しかしまた長くなってしまった……
# 削ったり分割したかったけど、いい加減アウトプットしたかったのでひとまずこれで。

目次

  • コード例
    • フィールド選択での例
    • ごく簡単な集計での例
    • ログ集計
    • まとめ
  • 第1回に対するネット上の声Q&A的なもの
  • 次回以降の内容

コード例

フィールド選択での例

前述の様に、ユニケージ開発手法では、原則半角スペースをセパレータとするフラットファイルをデータストアとして用います。
セパレータが半角スペースであることについては賛否両論有りますが、

  • シェルスクリプトが半角スペースを引数の区切りとして使っている
  • ユニケージコマンドの補助として多用するawkのデフォルトセパレータも半角スペース

であるので、それなりに合理的ではあると考えます。

簡単な具体例として、あるファイルの特定の列のみ選択する操作について説明します。
以下のファイルをサンプルとします。

このファイルから商品コードと販売価格のみを出力する場合は、
self コマンドを用いて以下のように行います。

上記と同じファイルをスクリプト内で読み込み、等価な標準出力を行うPHPのコードを以下に記します。

もうちょっといい感じにできるとは思うのですが、
単にフラットファイル丸ごと開いて数列を選択して出力するだけでも冗長な感じです。
# 強引だ……

ユニケージコマンドセットには、概ねこの程度の粒度のコマンドがたくさんあるのですが、
実務的には概ね数十程度(筆者の感覚では50以下)のコマンドの組み合わせにて、アプリケーションを記述しています。

また、前述の様に、ユニケージコマンドだけでは行いにくい処理を行う場合は、だいたいawkを使う事になります。
前述の self コマンドの例と等価なawkを使用したワンライナーは、書くまでもないかも知れませんが、

となります。
フラットファイルの行の集合に対して、各々フィルタ処理を行って目的の出力を得る、という処理が中心のユニケージに対して、
awkは枯れている上に、短いフィルタ処理を書く為には簡潔に書けるので、ユニケージ開発には重宝します。
# ただし、awkはなるべく使うな、というふわっとした規約もあったりします……
# 商用版ユニケージコマンドはほぼ全てpure Cで書かれているので、awkでコマンドの組み合わせに相当する処理を記述すると比較して十分に遅くなってしまうので……

ごく簡単な集計での例

前述の商品マスタを用いて、さらに販売実績に関する簡単な集計の例を示します。
以下の様な販売実績のファイルがあるとします。

上記の販売実績から、店舗と販売日問わず商品毎の販売合計金額を算出する場合は、以下の様にします。

join1コマンドは、指定したキーにて、2つのファイルまたはファイルと標準入力に対して、内部結合を行うものです。
ユニケージコマンドでのキー指定は、極一部の例外を除き、事前にそのキーにてソートされている必要があります。
lcalcコマンドは、基本的な算術演算をawkのようなシンタックスの式で、
36桁の10進数で加減乗除と四捨五入・丸め操作を行うものです。
sm2コマンドは、第1,2引数で集計範囲キーを指定し、第3,4引数の範囲の値の総和を個別に取るものです。

また、店毎のある日の総販売実績は以下の様にして求められます。

集計したいキーと集計したい値だけに着目し、コマンドを作用させれば求める値が得られる、というのは、単純な算術演算だけ行うようなロジックにおいては、他にケアするべきことが少なくなるのでよいです。

ログ集計

簡易なWebサーバのステータス集計など、ログ集計も可能です。
例えば、以下の様なフォーマットのログのみが /var/log/httpd/access_log に出力されている場合、

1時間毎のステータスコードを以下の様に集計出来ます。

yarrコマンドは、指定列数になるようにファイルの行を横に展開するものです。
countコマンドは、指定キーにマッチする行の数をカウントするものです。
ログ集計がシェルスクリプトで、下手すればワンライナーで完結するので、あまりアプリケーションコードを書かない方のインフラエンジニアの方やデータ分析官の方にも重宝するのではないでしょうか。
yarr,count共にOpen版に含まれているので、こういった作業をすることがあるならば導入しておくと便利です。

まとめ

普通のプログラミング言語よりも、手続き的な処理が少なく、データに対する操作が主になっている様子を掴んでもらえたと思います。
例示したように、1つのプログラムで、前述の例の様なパイプライン処理で作成した複数のデータを、一時ファイルに置きつつさらに操作して、最終的に求める出力を得ます。
求める出力は、DBのビューに相当するデータであったり、HTMLテンプレートにはめ込むデータであったり、バッチ処理により更新されたテーブルであったりしますが、基本的な手法はほぼ変わりません。
アプリケーションコードが殆どデータに対する宣言的操作だけでできている、と言えます。
基本的には無名のフィールドに対して操作を連続して行い、操作中にフィールド構成がよく変化するので、変化ある毎にフィールド内容を正しくコメントすることは必須です。
これを正しく行っていないと、人間非可読なコードがあっという間に出来上がります。
しかしながら当然あり得るツッコミとしては、コメントが多すぎて可読性がひどいのでは、というのがあります。
これに関しては、また次回以降……

第1回に対するネット上の声Q&A的なもの

エゴサ力を駆使したところ、第1回公開後のネット上の声が思ったよりあったので、勝手に回答します。
ソースは必要があれば正しくURLを引用しますが、晒す感じになってしまいそうなので、 意図を歪めない範囲で省略した文に対してインライン回答する形式にします。

プログラマ視点で引き続き解説を

そのようにしていきます。
ビジネス中心の話はビジネスおじさんに任せればよいのです。
小耳に挟んだところによると、色々な所から人を集めて推進するようなプロジェクトでもユニケージ案件は一定数存在するようなので、そこに突っ込まれた普通のエンジニアにとっても有益なものになるようにしたいです。
また、公にされている情報がビジネス的な話ばかり目立って存在して、技術寄りの話が少ないテクノロジーというのは、はっきり言ってエンジニア視点からは胡散臭さマシマシとなり、それ自身にとって不幸だと思うので、引き続きこのくらいのスタンスでやっていきます。

考え方が関数型言語っぽい

せやな。
……などというとマサカリが四方八方から飛んできそうです。
その上で言うと、

  • データ構造が2次元配列だけの、シンプルなデータ構造で
  • しかもデータソースでもアプリケーション中でも出力でも構造が殆ど変わらない
    • 所詮はフィールド数が多いだけの、テーブルに出力する一覧画面や帳票リプレースものなアプリケーションが多い。
    • 更新系も、所詮表形式データの編集に過ぎないものが多い。

最も抽象度の低い宣言型プログラミング、とも言えるかも知れません。
そろそろ強いマサカリが怖いのでこの辺で……。

これについては、より知見の深い、シェルスクリプト高速開発手法入門で皆様ご存じの上田先生にもご意見を賜りたく。
シェル芸とHaskellの対応を考える | 上田ブログ

エンドユーザーコンピューティングとしてはmuch better Excel。ファイルシステムというドキュメント型KVSの上に実現するための知見の集合?

確かにExcel/Accessによるエンドユーザたこつぼシステムの代替である側面はあります。

ユニケージコマンドがフラットファイル処理に特化しているので、ファイルシステム上のフラットファイルに、という感じではありますが、
ユニケージにはデータの階層構造の概念があり、それが実現できればファイルシステム上のフラットファイルでなくとも、ユニケージ的なものは出来そうです。
例えば、AWSやAzure,GCPなどのクラウドのマネージドサービスにて、各々のデータ階層のデータストアとしての役割や、データ操作の役割を割り当てる、など考えられます。
単純にファイル置き場をS3にして実現したシステムの事例については、
既に当社の田部井による事例紹介が公開されています。
フラットファイルを用いないユニケージ的な考え方については、
ユニケージのデータの階層構造を説明する時に、考えながらあわせて触れたいと思います。

また、等価なコードはだいたいの言語で書けるはずなので、言語もシェルスクリプトである必要はないと思います。

# 個人的にはシェルスクリプトはあまり好きではないし、追加・削除したコード量的にも、一生のうちに書いてよいシェルスクリプトの閾値を超えた気持ちになっているので、おなかいっぱいです。
# あとシェルスクリプトは他の言語に比べて簡単かというと、そうでもない。
# ユニケージコマンドやそれに類するコマンド群がなければ、アプリケーション記述用言語としては初心者に全くおすすめできません。

RDBMSを使用しない理由が不明確

これは確かにそうです。
私はユニケージガチ勢ではないので、普通の言語や普通のRDBMSや普通の分散環境がはまるケースなら普通にそれでやればいいと思います。
適材適所、ユースケースにはまれば採用すればよい。

その上で、エンドユーザーコンピューティング的な視点だけで言うと、
諸々の実行環境やミドルウェアの設定・依存関係に悩まされず、ユーザが脱Excel|Accessして、
自社のデータを自分の手で素データからガンガン取り回すという経験を最速でやれるのは、ユーザ企業にとって、自社を動かすシステムのブラックボックス度を軽減させるという点で、重要な事と考えています。
システムを作ることから離れすぎた・放棄したユーザ企業が、SIerに上手に仕事を投げられなくなり、
ダメなSIの発生率が上がっていそう(ダメSIの定義が出来ていないので妄想みたいなものですが)という気がしますので。
もっと言えば、SIに限らずWeb制作などの、一定以上の専門性を要するものの外注などにも、発注側の過度の “わかってなさ” が良くない事態を招くこともあると思います。
# 自分が何をわかってないかをわかってない人と仕事をするのはつらいです。

システムの物理的実体がRDBMSを使っているかどうかなどの適材適所とは、また別の軸の話となってしまいました。
とりあえず、バージョンや設定に依存するミドルウェアやコンパイラ・インタプリタが事実上ほぼ無いと言える(一応Apache httpd とbash、ユニケージコマンドに依存するが)というのは、
ユーザ企業出身エンジニアにとっては、余計なことを考えず自社のデータのことだけを考えればよい、という点が良いのではないか、と考えています。
筆者はハンズのプロパーではないので、他のプロパーの人たちを見て、という意味です。
エンジニアとしての練度が上がり、業務だけでなく技術に対する理解力もついてくれば、
なんでもユニケージでなく、ケースによって最適なアーキテクチャをエンジニアが選定して推進していけばよいのではないでしょうか。

あんまビジネスの話したくないけどそれっぽい話をしてしまった。あかん。

シェルスクリプトでJSON操作できるコマンドが必要では

ユニケージコマンドには存在しないのですが、一定の範囲では間に合ってますw
例えば、

みたいな入力を食わせると、

みたいなJSONを吐くコマンドは2年以上前から社内に存在してます。
上記のような、
キー名 値
が連続したファイルを読みこんでjson_encodeするPHPのスクリプトを外部コマンドとして作成し、使用していました。
# しかしシェルスクリプトでJSONパーサ書くとかぞっとする……。
また、AWSのCLIを使用する際などは、jqコマンドを使用してレスポンスをパースしています。

シェルスクリプトでJSONを操るのは、少なくとも弊チーム(EC・アプリ系)は色々あって卒業しました。
色々、については、書く機会があればそのうち書きます。

次回以降の内容

次回は、ユニケージのデータ階層構造の概念について、を予定しています。
可能であれば、クラウドマネージドサービスとの対応を考えてみるところまでやってみたいと思います。
pros/cons については、次々回以降に、ここまでの記述で書いたこと、察せそうなことをまとめる形でやっていく予定です。

第3回はこちら


S3をDB利用したポイントシステムについて話しました


田部井です。
時間が立ってしまったのですが、2月7日に新大阪で開催されたカンファレンス『JAWS-UG KANSAI 特別編』のハンズラボ枠の中で20分ほど講演してきました。
カンファレンスのテーマが「AWSを使い倒せ。AWSのフルマネージドサービス活用によるネイティブクラウドシステムへの誘い」ということなので、S3を活用して構築したシステムの事例をご紹介しました。
その際の私のパートの資料をUPしました。

S3をDBとして使っていること、ほぼ素のAWSとLinuxの機能だけでイミュータブルインフラストラクチャーに近づけたことが、このシステムのポイントになっています。

S3をDBとするにあたり、これまで東急ハンズのシステム内製構築で培ってきたユニケージ開発手法のノウハウを使っています。
クラウドとは親和性が低いと思っていた『テキストファイルデータ管理』が、新しいCDPに繋がったと自画自賛しています!

ユニケージ開発手法に関しては、こちら
謎テクノロジーの一端を見ることができます

今回私の初めての講演だったので、色々いい勉強になりました。
来る3月22日のJAWS DAYSでも話すかもしれないので、ぜひご来場ください!


12