2019/02/02に行われた「沖縄・宜野湾エンジニア勉強会 #6 in ギークハウス沖縄」に参加して、「Paykeの技術基盤チームの取り組み」というタイトルで発表してきました
タイトルどおりなんですが、2019年2月2日にギークハウス沖縄で行われた「沖縄・宜野湾エンジニア勉強会 #6 in ギークハウス沖縄」に参加して、「Paykeの技術基盤チームの取り組み」というタイトルで発表してきました。
もう結構時間あいちゃっているんですが、自分のためのログとしては残しておきたいのでブログを書いてます。
去年はコミュニティへの参加は控えていたんですが、今年はやっていくぞ！という目標も立てていたので、発表にも応募。 2018年10月から技術基盤チームを設立して、約4ヶ月程度チームで取り組んできたことを整理して発表してきました。
発表資料はこちら。
他の登壇者の方もかなり面白くて、エンジニアの生存戦略、資本主義ゲームの戦い方、Web技術で定規を作ったり、JSの仕様を駆使した黒魔術を披露したり、K8sの話があったりと盛りだくさんの多種多様な話があり、最高に面白かったです。
登壇資料をまとめてくださっているので、ぜひ見て下さい。
あと何より良かったのはギークハウスのコーヒーが美味かったのとWifi環境が爆速だったことですね！
2次会には諸事情で参加出来なかったのが残念でしたが、トータル最高に楽しかったです。
ありがとうございましたー！！
「沖縄のスタートアップ企業で働くエンジニアのリアル」というイベントでパネルディスカッションに参加してきました。
主催の方からご連絡を頂き、「沖縄のスタートアップ企業で働くエンジニアのリアル」というイベントでスタートアップで働くエンジニアの一人としてパネルディスカッションに参加してきました。
30人もの参加者に来て頂き、沖縄の中でスタートアップでエンジニアとして働くという注目度が高くなっていると実感しました。 参加者には現在エンジニアとして働いている方と、プログラミングスクールなどを出てこれからエンジニアとして働きたいと思ってスタートアップに興味を持った方が大体半々くらいいる感じでした。
パネルディスカッションでは事前にテーマが設けられており、それに関して話していく、その中で会場からの質問があれば答えていく構成になっていました。
このブログでは僕が回答した内容をまとめておこうと思います。
パネルディスカッション
大手企業とスタートアップ企業の違い
僕の場合は前職も入社したとき社員が約15名程度だった会社がその後70名まで成長したようなベンチャー企業で、今回も10名いないくらいのときに入社し現在40名以上に成長しているスタートアップ企業なので、まず大手企業のことを知らないという前提で話を聞いてほしい。
僕の場合スタートアップ企業の大きな特徴はその変化の速さだと考えていて、エンジニア目線でも求められるもとがどんどん変化していく。
たとえば立ち上げフェーズであればそもそもそのプロダクト自体が世の中に受け入れられるかわからない状態なので、品質よりも速く開発してリリースすることが求められる。 ある程度受けいられるということがわかり投資を受け、エンジニアの数も増やすフェーズになれば開発自体はもちろん高速で進めつつも、品質を高めることやチーム開発のための体制を整えることも必要になってくる。 さらにチームも増えたり会社としてデータドリブンな意思決定をしていくためにデータ分析のための基盤を整えたり、継続的な開発を行えるようにミドルウェアやフレームワークのアップデートを継続的に行うため体制や仕組むを作るなども求められる。
このような変化が１年や半年どころか3ヶ月単位のレベルでやってくるのが、変化のスピードが早いスタートアップ企業の特徴だと思う。
なぜスタートアップ企業を選んだか？
転職活動中に今の会社以外からも複数社からオファーがあり話を聞いていたが、自分が入ることで最も価値を発揮できる、成長を加速させることができる会社を選んだ。
僕が入るときは次の投資が決まる前だったので、可能性としては入社して３ヶ月後には潰れるという可能性もあるとは思っていた。 ただ僕が入ることでプロダクト開発を加速させ、エンジニア組織を強化し会社としてもプロダクトとしての価値も上げられると考えたのでいまの会社に参加することを決めた。
エンジニアとしての成長はあったか？
会社の成長・変化の早さに合わせて、エンジニアに求められるものも変わりそれに答えているうちに成長出来ていたと思う。
いまも開発組織をスケールさせていくために技術基盤チームのプレイングマネージャーとしてエンジニアリングとマネジメントの両方で様々な仕事を行っているので、さらに成長できると考えており楽しみ。
親や周りの反対はなかったのか？
仕事を辞めるのも決めるのも基本的に自分判断で親への相談とかは特に問題なかった。
結婚しているので嫁ブロック的な話もあると思われるが、うちの場合は嫁も同じスタートアップ企業で働いているので、全く問題ない。
給与的には入社時は会社自体がお金のない時期だったこともあり前職のときよりも給与を下げて入社したが、いまはもうその額は超えている。
実際、残業は多いのか？
スタートアップやベンチャーの特にITは残業が多いイメージが強いと思うが、今の会社の場合はゼロではないがかなり少ない。
アプリやその他のバックエンドシステムをリニューアルをしたときには残業が発生してかなり忙しい時期もあるが、平均的には残業せずに定時で帰っている。僕らの場合既婚者や子供がいる社員が最初の10~20名程度のときからいたため、働き方の健全性も高いし、自分たちの状況に合わせて柔軟にリモートワークをしたりすることも普通なのでかなり働きやすい。
沖縄で就職する理由
子供も生まれたこともあり、子育ての環境として実家がある沖縄は快適なのでそのまましばらくは沖縄で働きたい。 ただ、単純にエンジニアとしての成長ややりがいだけを見たら東京の方がコミュニティも面白い会社も多いので東京に行くのが最適だと思う。
自分が楽しくエンジニアとして生きていくために必要なのは良質で多様なエンジニアコミュニティと高い給料が払えつつかつ面白いプロジェクトをしている会社とそこに集まってくる優秀な面白い人々だと思っている。
沖縄で快適に子育てしつつ、そのエンジニアとしての環境を自分で作っていけるようにコミュニティ活動をしたり、今入っているスタートアップ企業を成長させて高い給料がはらえつつ面白いプロジェクトをしている会社にしていこうと思って沖縄で活動している。
会場からの質問
沖縄のコミュニティや会社などエンジニアを取り巻く状況の課題はなんだと思いますか？
僕は沖縄以外の場所でエンジニアとして働いたことはないが、コミュニティ運営などを通して知り合った県外のエンジニア方々の話や僕の肌感覚としては、沖縄はエンジニアのコミュニティも活発だし優秀なエンジニアも多い。しかしそこで育った優秀なエンジニアがその価値を発揮したり更に成長できるようなプロジェクトを持った会社が少ないし、その価値に見合った給料を払える会社も少ない。
そのため沖縄のエンジニアとしてのキャリアパスがある一定のレベルを超えるとフリーランスになるか東京の会社に転職するしかない。
その課題を解決するために、僕はスタートアップの中で会社を成長させ、優秀なエンジニアに見合った給料とプロジェクトを提供出来る会社を作ろうと活動している。
スタートアップに入社したいと思っているが、そういう会社にどうやったら出会えるか？
エンジニアとして成長するための活動を活発に行っていればいいと思う。ここで言う活動とはOSSや自分のソフトウェアを開発して公開したり、コミュニティに参加して運営したり登壇したり、ブログを書いたりすることです。
僕らが会社を探すよりも遥かに強いモチベーションでスタートアップに限らずソフトウェアを扱う会社はエンジニアを探している。そういう会社は必死に探すので、上記のような活動をしっかり行っていれば比較的容易に出会えるようになると思う。
さいごに
去年は初めての子供が生まれたという状況だったのでコミュニティ活動はセーブしていたんですが、今年はより活動を増やしていこうと考えていました。 その状況で声をかけていただいたので喜んで参加したのですが、沖縄でスタートアップのエンジニアというものに興味がある人がこんなにいたことに驚きました。
また「私もスタートアップでエンジニアとして働きたいと思っている」というプログラミングスクールという方もいました。
その方々とTwitterでつながると作品として普通に面白いアプリを作っている方もいたので、いままでは経験者の採用のみに絞っていたのですが、これからはまだ業務経験はないが１年程度で会社のアベレージを超えていけそうな人を採用していくというのも全然ありだな〜と考え直す良いきっかけにもなりましたし、僕も刺激になってより一層頑張っていこうと思えるきっかけになりました。
イベントを主催してくださった方々や会場提供してくれた方々、一緒にパネルディスカッションに参加してくれた方々に参加者の方々も皆さんありがとうございました。
AWSユーザーにも知ってほしい、Azure Web AppがWordPressを乗せるのに最高という話
Azure Web Appとは
Azure Web AppとはAzureが提供しているPaaSの一つです。 その名の通りWebアプリを乗せるために適したPaaSで、負荷分散や自動スケーリング、またGit等を利用した継続的デプロイなどの機能も提供しています。
対応している言語が2019/1/20現在で以下のようになっています。
WordPressをPaaSに乗せる上での課題
WordPressに限らないのですが、PaaSにWebアプリを乗せるときにはWebアプリ自体を「ステートレス」にしないといけません。 ステートレスとはその名の通り状態を持たないようにすることで、WordPressの例でいうと管理画面からアップロードする写真やインストールするプラグインがそれに値します。
PaaSはスケールアウトとスケールインといって、インスタンスを増やしたり減らしたり出来ることが大きな魅力の一つです。 しかし一つのサーバーの中に画像やプラグインのファイルが配置されていると他のサーバーからそのファイルが参照できないためにスケールアウトできません。
そのためPaaSにWordPressを乗せる場合には画像を専用サービス(例: S3)に送信したり、プラグインをgit管理して管理画面からは更新やインストールをしないようにするなどの運用にする必要があります。
しかし、画像をS3にアップロードするように修正するのも工数がかかりますし、プラグインをgit管理する場合はプラグインのインストールを開発チームが行わないといけなくなります。
Azure Web Appの何がWordPressに適しているのか？
Azure Web Appは状態があるWebアプリでもスケールアウトすることができる特徴があり、そのためWordPressに乗せるのに特別な改修をする必要がありません。
利用者側が気にすることはないですが、Azure Web Appの内部はざっくりいうとWeb WorkersとFile Workersに分かれています。
Web Workersが実際にリクエストを処理しプログラムが動作するサーバーになります。スケールアウトをしてインスタンス数を増やすとこのWeb Workersの数が増えます。
File Serversはhtmlやjs、画像やデプロイされるコードなどのファイル類が配置されているサーバーになります。これはAzure Storage Blobsがマウントされており、Web WorkersはFile Serversにnetwork driver越しにアクセスしています。
例えばインスタンスが3つに設定されたWebAppに載せたWordPress 上に画像をアップロードされると、プログラムレベルではサーバーのローカルディスクに保存しているように見えますがネットワークドライバー越しにFile Serverに保存されます。そのファイルを3つのWeb Serversから参照できるのでインスタンス数を増やしても減らしても大丈夫というわけです。
というわけで、もしWordPressのサイトをクラウドにのせたい場合はいつもはAWSを使っている方もぜひAzure WebAppを候補にしてみてください。
参考URL
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にそっとスターを押して頂けると嬉しいです笑
