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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

カテゴリー: ユニケージ

CRMチームの技術展望

Pocket

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

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

過去 (2015年度以前)

  • 外部ベンダ製のパッケージから内製化への移行期。
  • オンプレミスなサーバからAmazon EC2へ移行。
  • Web・Web API・バッチの全てをユニケージ開発手法(以下、ユニケージ)で開発。
  • 開発・運用とも元販売員エンジニアが実施。

現在 (2015年度〜2018年度)

  • ほぼ内製移行が完了。AWS移行も完了。EC2以外のサービス利用が増加。
  • ユニケージが不向きと判断したシステムについては言語をPHP/Node.jsへ、データストアをDynamoDB/RDSへ移行。
  • 東急ハンズ出向者が減り、中途採用の専業エンジニアによる開発・運用。
  • ハンズラボ社としての新卒採用を開始。

過去と現在の差分

  • 内製化により、ブラックボックスとなっている箇所がごく少ない状態になった。
  • AWS化により機器故障等のハードウェア運用作業がほぼゼロになった。
  • AWS化・多言語化・NoSQL/RDB化により、必要な技術知識の幅が大きく広がる。
  • 「業務知識>技術知識」な開発者から「業務知識<技術知識」な開発者へ。

近い未来

  • 開発者が業務知識を持つ状態から、コードが業務知識を表す状態へ遷移する。
  • コードレビュー・モブプログラミングによる暗黙知の継続的な転移。
  • コンテナ技術の利用による開発言語・ツールの選択肢の増加とdeploy単位の細分化。
  • 新規参画メンバーの早期戦力化のためのオンボーディングプロセスの改善。

まとめ

より、エンジニアにとって魅力あるチームへ変えていくことが自身のミッション、と捉えています。
自チームを「参画すると成長できる」「他社・他チームから入りやすい」「休みやすい・在宅勤務しやすい」「自分が選んだ技術を使える」ものへ変えていきたいです。
先日の清水の記事「バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1」はその実践の一つです。

まだ残っている2015年度以前に開発したアプリケーションもあり、順次マイグレーションを進めています。開発プロセスの改善を継続しながら、近い未来をより早く引き寄せるために、マイグレーションの速度も加速させていきたいです。

まだ、「遠い未来」については描けてはいませんが、チームのメンバーと一緒に考えていきます。
新規メンバーの募集と受入のため、「チームのJobDescriptionの作成」「OnBoardingプロセスの文書の作成」を並行して作成しています。
こちらも、いずれ公開したいです。
生煮えのプライベートリポジトリ版にご興味のある方は、ぜひ中途採用にご応募ください。その時点の最新版をお渡し致します。

※アイキャッチはフリー写真素材ぱくたそhttps://www.pakutaso.comさんの画像です。

Pocket

混ぜるな危険!? ユニケージとxonshの融合

Pocket

はじめに

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

ユニケージとは

個人的な解釈ですがawkで頑張らずともユニケージコマンドを使用することで比較的楽にshell芸ができます。

一例ですがこんなことができます。

このファイルの2列目の値だけ欲しい。
awkで書くとこんな感じ。

ユニケージコマンド(self)を使用するとこのようにかけます。

僕はまだユニケージ初心者なのでより詳細な情報は以下の記事を参照してください。

xonshとは

Pythonで作られたクロスプラットフォームのUnixライクなシェル言語とコマンドプロンプトです。
Pythonの対話モードとUnixコマンドが合体したみたいなものです。

個人的にshellなるべく書きたくないマンなのでPythonで書けるのは衝撃でした。

pipで入ります。使用するときはターミナルでxonshと打つと起動します。

ライブラリも使用できます

詳しくはこのアドベントカレンダーのリーダーである@vaaaaanquishの記事をご覧ください。

今回紹介すること

今回は謎技術ユニケージとxonshを組み合わせた「ひょっとしたら、これ使えるかもしれない(笑)」的なものを紹介していきます。

selfとのコラボ

先ほど使用したselfコマンド。このコマンドはawk '{print $1 $3}'のように出力したいフィールドを指定することでそのフィールドを表示します。

xonshと組み合わせる

いつ使うかよくわかりませんが、まぁ便利そう(pandas使ってもいいんですけどね)

殺人的なワンライナーも書けます。

mdateとのコラボ

こののコマンドは開始日から終了日を全てスペース区切りで表示します。
mdate -e <開始日(yyyymmdd)> <終了日(yyyymmdd)>

xonshと組み合わせる

split関数がいい感じにスペース区切り文字列を分割してくれるので20181201から20181231までのリストを生成できます。これは割と使えるのでなないかと個人的に思っています

dayslashとのコラボ

説明するよりも見た方が早いです。

いい感じに/を入れてくれます。 1はフィールド指定です。

xonshと組み合わせる

date_listから受け取ったdateをdayslashで/を入れてslash_dateに格納します。\nが入ってしまうのは勘弁。

Jupyter Notebookで使用する

いつものようにJupyter Notebookを使用して新規ファイルを作成しようとしたら,Xonshが入っていることに気付く。
どうやらpip install xonshするだけでJupyterのカーネルに追加されるそうです。

ユニケージコマンドは果たして使用できるのか?

実行できた!どうやらローカルのコマンドも使用できるようです。

ちなみにGoで作成したコマンドも使用できました。

Pocket

GolangでDynamoDB CLIを書く話

Pocket

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さんです。

Pocket

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

Pocket

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

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

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

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

について議論します。

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

目次

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

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

    • pros
    • cons
  • 連載のまとめ

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

Pocket

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

Pocket

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

Pocket