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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

社内勉強会で型について話しました


ハンズラボでは、 全部JavaScript でいくでーの長谷川の大号令が有り、
キャッチアップに危機感を持ったり単純に楽しみたいなど色々な人が居る中、
毎週1回有志でわいわいJavaScript に関する勉強やちょっと作ってみた会をやっています。
最近の私には、以下の問題意識があります。
エンジニアとして東急ハンズ及びハンズラボに入社してきた訳ではないが今エンジニアをしているというメンバーには、ドメインエキスパートとしての強みがありますが、さすがに軽減しておいた方が良い弱みがあると考えています。
それが、型という概念です。

ユニケージにおいては、プログラミング言語(一旦マークアップ言語は省きます)としてはほとんど以下のような状態であり、ドメインエキスパートなメンバーはほぼこれらのみしか触ったことがないという現状です。

  • シェルスクリプト
    • bash 以外での動作は想定してない。必ずしもPOSIX準拠ではない。
  • awk
    • 書式指定
    • フィルタ
    • 簡単な算術演算
  • JavaScript
    • 一部の人はjQueryゴリゴリ書く。
    • 生のJavaScriptに関してはみんなぼちぼち。
      • コピペも結構横行している。

シェルスクリプトは文字も数字もだいたいよしなにしているし、
awk は文字列と数字の暗黙の型変換や変数初期化がPHPの真偽値どころでない適当さだし、
JavaScript はダック・タイピングでこれもまたなんか色々とだいたい動く感じにしてくれてるし、
いずれも強い静的型付け育ちの人間から見ると、さすがにちょっとフリーダム過ぎて逆に初級者にははまるとつらいだろ、と思っています。

なので、型ってなんや、みたいなメンバーに、こういう仕組みがある、
というのを、ちょっとだけ説明するスライドを作って、先週の社内勉強会で話しました。

概ね好評ではあったのですが、書けば書くほど自分の型に関する理解が浅いことを思い知らされ、
かつその浅い理解では思い切った初心者向けの説明をするのも危険であるな、と思いつつ、
基礎を復習しながらなんとか書き上げた感じです。

ハンズラボではAWSべったりバッチコイWebアプリケーションエンジニアを募集しておりますが、
全体の基礎力底上げのため、上記の様な人でかつさらにコンピュータ科学にも明るい人も個人的には来て欲しいです。
ご応募お待ちしております。
AWSでエンタープライズシステムを構築するエンジニア、Wanted!!


AWS Summit Tokyo 2015 DevConで話してきました!


今井です。

6月2日、3日に開催されたAWS Summit Tokyo 2015の開発者向けカンファレンスの方で、 iOSとAWSを利用したPOSについて話してきました。

以下は、その際のスライドです。

カンファレンスの後のJAWS-UGでやっていたAWSウルトラクイズで三位になりました!
景品でクラウドデザインパターン 設計ガイド 改訂版をいただきました!(ヤマンさんにサインもらい忘れた)
これを読んで次回は一位を取れるようにがんばります!

なお、ハンズラボでは、AWSエンジニアとiOSエンジニアを募集しております。
一緒に2-Tierアーキテクチャなアプリケーションを構築したい、という方はぜひこちらから応募ください!!!

AWSのフルマネージドで、アプリ構築するエンジニアWanted!


ハンズラボが採用しているユニケージという謎テクノロジーについて 第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フルマネージドなメタユニケージではそれがどのように変わるか
について議論したいと考えています。


PHPカンファレンス2015関西に参加してきました。


qmailなどの作者の djb がまだ43歳だったということに衝撃を受けている井上です。

先日行われた、PHPカンファレンス2015関西に参加して来たので、その感想などを書いてみたいと思います。

IMG_5307

まず感じたのが、PHPの時期メジャーバージョンである PHP 7がとても期待できるということ。

基調講演の『PHP 7で変わること 言語仕様とエンジンの改善ポイント』
を聞いて、若干の遅れはありつつも、リリースに向けた作業は順調に進んでいるということ、また圧倒的なパフォーマンス改善ぶりに、早く使ってみたいと思える内容でした。
速度的には、Facebookが開発した別の処理系であるHHVMとほぼ互角であるとのことです。

改修の内容を見ても、今回のパフォーマンス改善だけではなく、今後、言語の構文の改善がしやすいような足場づくりもきっちり進められており、7の次のバージョンに向けても期待が持てるように感じました。

他のセッションでは、テスト、継続的インテグレーションや、スクラム開発などまだまだハンズラボとして取り入れられていない部分について刺激を受けました。
ひとっ飛びに発表されているような開発体制にはできないと思いますが、できることから1つずつ取り入れて行きたいと思います。

また、今回『PHP x AWSでスケーラブルなシステムをつくろう』という内容で発表を行いました。
サービスを成長させていく中で問題が起きがちなポイントと、AWSを使った解決方法についてストーリー仕立てでお話させて頂きました。

他社で当然のようにやっていることが、自社では出来ていなかったり、自社でできていることが、他社ではまだまだできていなかったりと、コミュニティで交流すると情報交換できてとても良かったです。

IMG_5316

懇親会もとても盛り上がりました。スタッフの方お疲れ様でした!

IMG_5315

なお、ハンズラボでは、PHPの他に Node.jsにも力を入れていこうと思っています。
もしAWSやNode.jsの開発もやってみたい、という方はぜひこちらから応募ください!!

AWSのフルマネージドで、アプリ構築するエンジニアWanted!


One Day Outing


つい最近、ハンズラボでは、月に1日だけ社外勤務ができるという制度ができました。

ネットの繋がるところならどこでもOK(たぶん)。
たまにはいつもと環境を変えて仕事することで、いろいろこびりつかないようにしようという取り組みです。

そこで本日、まさに今、この制度を活用しています。
訪れた場所は・・・ 続きを読む One Day Outing


  • IT酒場放浪記 記事一覧
  • エンジニア募集中!