Facebookが提唱するアーキテクチャ、FLUXとは単一方向のデータフローを実現するためのもの
FLUXとは ~ 概要 ~
Facebookが提唱している、UIを構築するためのアプリケーションアーキテクチャです。 Reactと一緒に語られることが多いですが、FLUXは特定のツールに依存したフレームワークではなくアーキテクチャのパターンの一つなのでReactを使わなくても実装可能です。
FLUXの特徴は、Action → Dispacher → Store → View と単一方向のデータフローによってUI設計をしていることです。 これによりデータフローによる複雑性をへらし、コードの可読性や堅牢性を高めています。
従来の手法とはなにが違うの？
よく比較されるMVCアーキテクチャとの違いは、データフローを単一方向に限定したこと。 MVCのControllerとModelは複数のモデルとControllerが相互にデータをやり取りすることで状態を把握することが困難なりがちだが、FLUXは単一方向データフローを実現することでこの課題を解決している。
技術や手法のキモはどこか？
Dispacherをシングルトンにすること、どのイベントに反応するかはStore側でハンドリングできるようにすること。 それによってStoreの追加による機能拡張も容易になる。
参考URL
Flux | Application Architecture for Building User Interfaces
flux/examples/flux-concepts at master · facebook/flux · GitHub
flux/examples/flux-logging at master · facebook/flux · GitHub
「サーベイログ」HeteroTSDB: A Time Series Database Architecture for Automatically Tiering on Deterogeneous Key-Value Stores
読んだ論文
https://yuuk.io/papers/heterotsdb_iots2018.pdf
どんなもの？
モニタリングサービスのインフラとなる時系列データベースに求められる書き込み性能、保存効率、データ構造の拡張製、スケーラビリティを実現するためにインメモリKVSとオンメモリKVSを組み合わせた異種混合KVSによる自動階層化する時系列データベースアーキテクチャ
先行研究と比べてどこが凄い？
先行研究ではデータストアが密結合であったため、データの拡張性が低かったが本アーキテクチャは疎結合のため拡張性がたかい(新たな性質を持つデータストアを組み合わせることが可能)
- InfluxDB
- OpenTSDB
- Gorilla
技術や手法のキモはどこ？
書き込み性能とデータ保存効率という性能要件を実現するために、特性に合ったDBMSを組み合わせたこと。
どうやって有効だと検証した？
書き込み処理効率の計測
オンディスクKVSに直接書き込む場合と比較し、インメモリKVSで書き込みを受けることにより、オンディスクKVSの書き込み回数が減っていることを確認する
データ保存効率
インメモリKVSへの書き込みを続けても空きメモリが0にならずにオンディスクKVSにデータを移動できているか確認する
書き込みスケールアウト性
各KVSのキャパシティを増加させたときに、分間書き込み回数がスケールアウトするかどうかを確認する。
議論はある？
とくになし
次によむべき論文は？
- The Log-Structured Merge-Tree
- Time SEries Management Systems
- BigTable: A Distributed Storage System for Structured Data
メモ
提案: HeteroTSDBアーキテクチャ 先行手法: OpenTSDB 高めたい指標: スケーラビリティ、書き込み性能、保存領域、拡張性を疎結合なソフトウェアとすることで実現、高可用性 データ構造の拡張性を考慮した時系列データベースは提案されていない→新規性 拡張内容に合わせた異なるDBMSを追加する疎結合なアーキテクチャをとりつつ、利用者からはREAD/WRITEのためのインターフェイスをそれぞれ一つに見えるように統一 書き込み性能→インメモリKVS データ保存効率を高める→オンディスクKVS AWSのサーバレスプラットフォーム上に構築することで異種混合DBMS構成を取りやすくしている→構築やスケールアウト作業の負担軽減 KVS間のデータ移動のためのタイマー手法 LSM-Tree(Log Structured Merge Tree)
2018年の振り返り
仕事
前半戦はionicframeworkを使ったスマホアプリのリニューアル & 新機能であるC2Cの商品売買マーケットプレイスの構築を行い、開発チームのリーダーとしてフロントエンドからサーバーサイドまでかなりがっつりコードを書いてました。
中盤戦はリーダー業を他のメンバーにお願いして、アプリの改善のための開発に集中。
後半戦は技術基盤チームという組織を立ち上げプレイングマネージャーとして、VMベースで展開されていた各サービス郡の可用性、冗長性を高めるためAzureのマネージドサービスに移行していきました。
SPAのフロントエンドからAPI & DB設計を含むサーバーサイド、クラウドサービスを使ったインフラ設計、開発チームのマネジメントという自分のオールラウンドな能力を生かした仕事が出来た一年かと思います。ただ前職自体に身につけた能力で戦った感があるので思い切り成長できたかというとそうでもない。
来年はもっと挑戦していくぞ。
- ionicframeworkを使って既存のAndroid、iOSアプリをリニューアル
- C2Cの商品売買マーケットプレイス機能の設計・実装
- サービスドメインによらない技術的課題を解決するための組織、技術基盤チームの立ち上げ
- テレビ放送に備えてコーポレートサイトをAzure CDNで対策
- VirtualMachine上のMySQLをAzure Database for MySQLに移行
- ファイルベースのキャッシュをAzure Redis Cacheを利用したキャッシュに移行
- ロードバランサーをAzure Load Balancerから Application Gatewayに移行
- 複数VMへのデプロイを行うデプロイツールを作成
- VM上にあったメディアサービスをAzure WebAppに移行
- Logic Appを使ってAzure上でモニタリングしているメトリクスの敷居値を超えたらSlackに通知するように構築
個人プロジェクト
今年は2つのソフトウェアを個人名義でリリースした。
ひとつはClojureで作ったWebサービスでプロジェクト共有サービスのCollabo。
個人で開発しているWebサービス「Collabo」をプレビュー版という形で先程公開しました😄https://t.co/Bz9qEBAa5T
— UG (@arakaji) 2018年6月28日
「Collabo」は「ビジョン」と「イシュー(課題)」と「コミュニケーション」をオープンにして誰でもプロジェクトを公開、参加できるアプリですので、興味あればぜひ使ってみてください🙏
もうひとつはPHP製のSQL マイグレーションツールのMig。
特別凄いソフトウェアでもないのだけど、僕的にはこの2つのソフトウェアはプログラマとしての「初めて」を達成出来たソフトウェアなので感慨深い。
Webサービスを開発するプログラマなので自分自身のオリジナルのWebサービスを作ってみたかったが仕事が忙しいということを言い訳に実現できなかったのですが、このCollaboで初めて実現できました。
Migは自分が作ったOSSで初めてGitHubのStarをもらったソフトウェアとなりました。
来年は「フォロワーのInputが追いつかないほどのスピードでOutputを」をテーマにどんどんアウトプットとしてソフトウェアをリリースしていくのでもっと多くの「初めて」が達成出来ると嬉しい。
エンジニアコミュニティ活動
ハッカーズチャンプルーの運営スタッフとして参加、Javakuecheの会長として2つの「アジャイルジャパンサテライト沖縄」と「Javakueche day」の企画・運営を行いました。 あと実験企画としてリモートもくもく会というビデオチャットを参加者でつないでもくもく会を行うという回も計9回ほど行いました(忙しくなってしまい、その後継続できなくなってしまい申し訳ない。。。)。前述したMigはリモートもくもく会で実装したものなので個人的には成果はあった。もしやりたいという人がいればまた再開してもいいかも。
ことしは運営は結構頑張ったんですが、自分で登壇したり他のコミュニティに参加するという機械がほとんどなかったのがちょっと残念だった。 来年は県内はもちろん県外のコミュニティにも参加していくぞ。
その他大きな出来事
子供が1歳まで無事育ちました。 子育ては圧倒的に時間を使うので自由に使える時間は減るのだけど、自分の人生の見方を大きく変えてくれました。
今までは「自分がプログラマとして楽しく過ごすには」とか「自分がプログラマとして生きるための生存戦略をどうするか」とかを大体長くても3年ぐらいのスパンでしか考えられなかったのですが、子供が生まれると「この子が生きる20年後のためにいま自分が何をすべきか」と考えるようになりました。
プログラマとしてもっと稼いだり成長するためにフリーランスになるであったり東京の会社に転職するであったり考えることもあるのですが、僕も嫁も沖縄出身で沖縄に親もいることを考えると子育てするのは沖縄の方がいい。ただ東京や海外と比べると沖縄には先進的な人や文化、技術も少ないので先進的な教育を受ける機会も少なく子供の可能性を減らしてしまう。なら、沖縄を先進的な人が集まり文化、技術が生まれる場所にしてしまえばいい。そのために僕がプログラマとしていま出来ることのひとつとして沖縄初のスタートアップを世界的なテクノロジーカンパニーに成長させることにコミットすることを選択していたりする。
あと、単純に子供はスーパー可愛い。
最後に
来年もさらにやっていくぞ。
テーマは「フォロワーのInputが追いつかないほどのスピードでOutputを」
Webフレームワークに依存しない、PHP製のシンプルなSQL マイグレーションツール「mig」を作った。
タイトル通り、特定のWebフレームワークに依存しないPHP製のシンプルなSQLマイグレーションツール「Mig」を作りました。
なぜ作ったのか
大体Webフレームワークにはこの手マイグレーションツールはついていますが、DSLを書かされたり、プログラミング言語の中にSQLを文字列として渡して実行するものが多いです。DSLだと抽象化されている分DB特有の機能が使えなかったり、文字列としてSQLを渡すのはエディタのシンタックスハイライトが使えないのも不便だと考えていました。
そのためマイグレーション用のSQLファイル生成の管理、マイグレーションとロールバックの管理のみを行い、マイグレーションのSQLも直接SQLファイルに書くことができるツールを作りました。
使い方
インストール
composer でglobal installします。
$ composer global require arakaki-yuji/mig
composerでmigがインストールされますので、実行できるように実行パスを通しておきます。
$ export PATH=$PATH:$HOME/.composer/vendor/bin
DBへの接続情報を記載した設定ファイルの設置
プロジェクトのルートディレクトリにmig.config.phpという名前でDB接続情報を記載した設定ファイルを設置します。
<?php
return [
'db_dsn' => '', // example: mysql:host=localhost:3306;dbname=project_db;
'db_username' => '',
'db_passwd' => '',
'migration_filepath' => 'migrations' // directory for place SQL scripts.
];
初期化
設定ファイルが設置されているディレクトリに移動し、初期化コマンドを実行します。
$ mig-cli init
するとマイグレーションの実行履歴を管理するmigrationsテーブルが作成されます。
マイグレーションファイルの作成
mig-cli create [名前] コマンドを実行すると指定された名前を使ってファイルが２つ作られます。
$ mig-cli create migration-filename Create a new migration file. ================= create migrations/20181121144957_migration-filename.up.sql create migrations/20181121144957_migration-filename.down.sql
up.sql がマイグレーションを実行するときに実行するSQLファイル、down.sqlがマイグレーションをrollabackするときに実行されるsqlファイルです。
たとえば itemsというテーブルを作るマイグレーションを作る場合、まずup.sqlファイルにテーブル定義のSQLを書きます。
CREATE TABLE IF NOT EXISTS `items` ( `id` int(11) PRIMARY KEY, `name` varchar(255) NOT NULL );
次にマイグレーションをロールバックする(もとに戻す)ときのためのSQLをdown.sqlに書きます。
DROP TABLE IF EXISTS `items`;
マイグレーションの実行
マイグレーションを実行は以下のコマンドを実行します。
$ mig-cli migrate
これで自分の環境で実行されていないマイグレーションが一度に実行されます。
ロールバックの実行
ロールバックの実行は以下のコマンドを実行します。
$ mig-cli rollback
これで、自分の環境で実行された最新のマイグレーションが一つロールバックされます。
終わりに
もし興味があればぜひ使ってみて、バグあればIssueもください！
あと、何も考えずGithubにそっとスターを押して頂けると嬉しいです笑
移動時間を作業時間に変えるためにバス通勤始めてみた
タイトルどおりでそれ以上言うことないのですが、バス通勤を始めてみました。
いままでずっと自動車で通勤していたのですが、最近やりたいことが多いわりに自由に使える時間は少ないのでどうにかして時間を確保しないといけないと色々生活週間を改善している。
その一つとして、車の移動時間が往復で1時間〜1時間半ほどあるのでまずそこを作業時間に当てるためにバス移動をはじめてみた。(このブログもバスの中で書いた)
まだ評価する段階にはないけど、とりあえず今の所本読む時間や作業する時間は増えるし、車の運転による疲労も減らすので割と良い。
あと、自分の移動時間、移動経路だと割と席も空いていて悠々と作業できそう。
ただバスの時間を正しく把握しないと30分~1時間とかバス待ち時間が発生するのでそれは気をつけないといけない。
5分おきくらいにバスが来る未来が早く来てほしい。
Azure CDNでWBS砲を迎え撃つ
先日、WBS(ワールドビジネスサテライト)に僕が所属している会社が取材され、短い時間ですが放送の中で紹介されました。
沖縄県知事戦を関連した、沖縄県で注目のITベンチャー・スタートアップとしてPaykeが紹介され、時間としては大体2分間程度だったのですが、テレビ放送ということもあり会社サイトにアクセスが急増することを想定してAzure CDNを使って対策を行いました。(放送があることがわかったのは、放送日前日の午後３時...)
CDNとは世界中に分散しているエッジサーバー上でコンテンツをキャッシュし、オリジナルのサーバーへのアクセスが届く前にエッジサーバーでレスポンスを返すことにより負荷分散とレスポンスの高速化を行うためのサービスです。
AzureのCDNの特徴として、Microsoft、Akamai、Verizonが提供するCDNサービスが選択できます。 それぞれ特徴が違うので、自分たちの用途にあったサービスを選ぶことができます。
今回は静的コンテンツだけでなくサイト全体をCDNでキャッシュして配信したかったため、そのためにはCDN側でSSL解決を行う必要がありました。 独自証明書を使いたかったので、それが使える Azure CDN Standard from Microsoftを選択しました。
CDNに独自証明書をアップロードするときですが、書式をpki形式に変換しないといけません。
証明書のcerファイルを以下のコマンドを使ってpki形式に変換します。
$ openssl pkcs7 -in {common_name}.cer -outform PEM -out {common_name}.pem -print_certs
以下ページも参考にしてみてください。
すでに稼働しているドメインをCDNに向ける場合の注意点
たとえばwww.sample.comというサイトをCDN配信するためには、DNSの設定でwww.sample.comのCNAMEの向き先をCDNのドメインにする必要があります。 新しいサイトの場合は問題ないのですが、すでに稼働しているサイトの場合に使用しているドメインの向き先をいきなり切り替えると、CDN側に設定が反映されるまでのタイムラグの間サイトが表示されなくなってしまいます。
Azure CDNではそのようなケースのためにcdnverify サブドメインをマップすることでCDN側の設定を事前に反映させることができます。 こちらのドキュメントを参考に設定してみてください。
オリジンとなるサイトがWordPressの場合の注意点
WordPressの場合、サイトのドメインがデータベース登録されているため、そのドメイン以外からのアクセスだとリダイレクトがかかるケースがあります。
wordpressに登録しているサイトドメインはCDNを向き、CDNからは別のドメインをつかってオリジンサーバーへはアクセスすることになるため、wp-config.phpの中で以下のようなコードを入れて、意図しないリダイレクトが発生しないように調整しました。
if($_SERVER['HOST_NAME'] === 'origin.sample.com'){
$_SERVER['HOST_NAME'] = 'www.sample.com';
}
結果
通常時の100倍以上のユーザーがサイトに訪れましたが、なんのトラブルもなく正常にサーバー稼働し続けましたので、今回の対策は無事成功したと思います。
実は今回がはじめてのCDN利用だったのですが、静的コンテンツの大量のアクセス増にすばやく対応するのに、CDNはさいつよですね。
