Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた

勉強会に参加させてもらったのでその時のメモやら

勉強会概要

atnd.org

www.youtube.com

発表

"Infrastructure as Code" から数年、結果どうなったか @naoya_ito さん

speakerdeck.com

日本語でいうところの冪等性=ReproducibleBuildちょっとしたキーワードだった。

自分はわりとそのままにしていた管理画面からのポチポチ業もReproducibleBuildしなきゃいけないなーと感じた。最近はDNSの設定でさえもコード化されていてサービス（プロダクト）を最速に提供する事が重要でそこに集中する為にという流れなんだろう。

AWSのIAMの設定重要っすね。

あとはモデリングの話で今の業務をそのままシステムに落とし込んで効率化や自動化を図っていくのが本質では無くて、複雑な業務をいかにシンプルにモデリングしてシステムに落とし込んでいくかが重要

自分もアプリケーション開発が主なのでアプリケーションを開発するときに考える、言語、FWの特性が今回の要件に合うかや正規化等々を想像したら分かりやすかった

最後にコンテナとかが出てきているのでモデリングがそこまで議論にならなそうって。

スライドに出てきた参考

12factor.net

Domain-Driven Design: Tackling Complexity in the Heart of Software

Infrastructure as Code と企業文化 @ryuzee さん

slide.meguro.ryuzee.com

クラウドがどんどん使われ始めてインフラなのかアプリなのかという境界線がどんどんなくなっていっている(同意)

採用アーキテクチャをうまく回していくにはやはり使う側の人・組織構造もセットで変えていかないとツライはなし（=コンウェイの法則）が出てきて最近別のところでも聞いた内容だったのでやはりそうですよねって思った。

同じくその際の注意点としてどうしても横断的に見た方が良いプロダクとの一貫性やセキュリティ面は考慮しておいた方がよいと。

なので共通するチームは残る。

文化面でのチャンレンジは正直相当ツライだろうなと想像してしまった。半端な決意では出来ないというか、、、相当な覚悟が必要

まぁ一気にやろうとすると正しい事でも爆死しますね。

Infrastructure as Code のこれまでとこれから mizzyさん

speakerdeck.com

現代の開発の三本柱の「バージョン管理」「テスト」「自動化」を実現した部分が大きいと。

Infrastructure definition toolsでTerraformは最近あまりよい話を聞かないなぁ。

Infrastructure as Codeを下記の分類に分けて説明していた部分はとても分かりやすかって理解の整理になった

• Dynamic Infrastructure Platforms
• Infrastructure Definition Tools
• Server Configuration Tools
• Infrastructure Services

ここでもコンテナの話やマイクロサービスの話が出てきて繋がってるもんだなと。

モニタリングとの融合の話で”テスト＝本番デプロイ前、モニタリング＝本番デプロイ後”はなるほど！

スライドに出てきた参考

Monitoring is Dead // Speaker Deck

運用・監視もコード化する。開発者が監視まで考える方法論 @songmu さん

運用・監視もコード化する。開発者が監視まで考える方法論

どんどんコード化され、インフラ・アプリの境界線が曖昧になってきているし、アプリケーションエンジニアはコードを書くのが得意な領域なのでどんどん取り組んだ方が良いと思った。

I Love Webhookの話はもっと色々と持ってそうでしたね。

今の会社でも最近Mackerel使ってるので聞きやすかったです。

プロビジョニングツールはMakeで決まりだろ @katzchang さん

speakerdeck.com

タイトルの釣り感がはんぱない。

プロビジョンイングツールでCofuってあったけど始めて知りました。 github.com

chefのcookbookレシピの中でmakeを書いてた過去を思い出しました。。。

まとめ

話を聞いていて最近特に調べたりする「マイクロサービス」「ThoughtWorks社」「Martin Fowler」「コンウェイの法則」とかのワードが出てきて、まぁ繋がってきますよねって感じました。DDDの話はちゃんと理解していないので勉強していかないとなと

最近Chefいじってなくて。別の同僚に任せきりになってることを反省した。Infrastructure as Codeでもちろん頑張って自分もコード書いていこうと思うと同時に構造もセットで変えていかなくちゃななー。スモールスタート。成功実例作り。んー胃が痛い

第16回elasticsearch勉強会に参加してきた

概要

下記の勉強会に参加した時のメモ elasticsearch.doorkeeper.jp

はじめに

よくある検索サービスやログ+分析と言ったところに使われるElasticSearchの勉強会

発表

LogstashとElasticsearchで作るEnterprise Search Platform Elastic Kosho Owaさん

今まではログ+分析、検索メインの使い方の紹介が多かったが、ちょっとそれとは違う話

内容的にはESP(Enterprise Search Platform)なので社内に保管・運用されている様々な形式のデータを横断的に検索するシステムの紹介と言ったところかな

Elasticsearch + Fluentのパターンで使ってる人は大多数でしたが、Elasticsearch + Logstashで使ってる人はちょっと少なくてネタになってた

以前近くにいた人と世間話をした際にその方が、社内の情シスの部門の方だった。自分はwebの人なので言い方むずいけど割と固い方もいるんだなぁと感じたが、こういう活用もあるのかとちょっと納得した。参加者の方でスーツの方が多いのはこのあたりかな

簡単に技術的なところをピックアップすると下記

• inotify
• fanotify
• vfs_full_audit

あたりを参照して

• Apache Tika Apache Tika – Apache Tika

• mapper-attachments-plugin github.com

あたりでExtractしてElasticsearchへindexさせている様子

あとはまだ下記の課題がある様子で改善に取り組んでいるみたいです

課題

• 検索UIが提供されていない
• 不整合発生時(sambaサーバとESの間での不整合)の解消方法
• 汎用性
• セキュリティ

企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用　株式会社ユーザベース 北内 啓さん @tau3000

企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用 from Akira Kitauchi

www.slideshare.net

企業、プロダクトの紹介

www.uzabase.com

• NewsPicksは色々見るけどSPEEDAはあまり見ないなー。と思ってたら、前者は個人ユーザ向け・後者は法人向けという事らしい
• デモで見たけど業界ごとの詳細レポートデータがかなり充実してた
• SPEEDAは下記の役割の人がいる
  • エンジニア、アナリスト、コンサルサービス（カスタマーサポートのような直接人がサポートするポジション）

本題

• いかにデータの隅々まで効率的にアクセスするかがポイント
• 過去には全てmysqlで対応していた時代があり、現地通貨のみで6億レコードが存在してた様子。もちろんmysql のindexがカオス問題に直面

と言った過去を経験してElasticsearchへ切り替えてた

インデックスに関して

• 1企業を1ドキュメントとして持つ。すべて1ドキュメントで持つ。mysqlでいうと１つのテーブルにすべて突っ込むイメージ
  • 財務や現地通貨、主要６通貨も一緒のドキュメントに持つらしいです
  • 1ドキュメトで最大約40MB、約11万フィールドに及ぶ

そんなに1ドキュメントにフィールドを突っ込んで普通に動くんだと感心した。

しかもバージョンは1.x

企業名検索に関して

• 日本語は文字bi-gram、英語は文字uni-gramで
  • uni-gramは流石にインデックスが大きくなりすぎるけど
• phrase_prefixを使う日本語は文字単位、英語は前方一致
  • max_expansionsを活用して制御を加えている
• 英語ではストップワードを活用
• 小規模なデータについてはRDBのデータの内容をオンメモリにして検索させてるのでElasticsearchと併用している
• ノードの役割分けは当初なく、Full GCが走ったノードに検索が走りのたびにツライ状況に
  • その後ちゃんと役割分けをして改善へ

最後にElasticsearchのバージョンアップとinner hitsに注目してると言ってたけど下記あたりをちょっとじっくり見てみるか

www.elastic.co

クローラーあたりの技術やノウハウもすごそうだなーと感じた

Elasticsearchベースの全文検索システムFess　株式会社エヌツーエスエム 菅谷信介さん

Fessというプロダクトをもとに発表されてた

Elasticsearchベースの全文検索システムFess from Shinsuke Sugaya

www.slideshare.net

オープンソース全文検索サーバー Fess — Fess 10.1 ドキュメント

• Fessというプロダクトで古くはNamazu、lucene、Solrあたりからプロダクトに活用していてその流れからElasticsearchを使っている様子
  • Namazuというワードは非常に懐かしさを感じてしまった。
  • 昔perlをよく書いててこの辺りに当たってよく調べた記憶がある
  • KAKASIとかもあったなー

• ロール検索というユーザによって検索可能な領域を限定して検索させる機能があるらしい

• plugin開発を多くしているようで下記にオープンソースになっている

github.com

• いろいろと見てみるとほぼ菅谷さん一人で書いている？w

形態素解析の辞書をカスタマイズしてクラスタに配るってゆう部分でElasticsearchに食わせる(indexさせる)時に使う辞書と検索の時に使う辞書を合わせないと期待値がずれる場合があると。確かに陥りそうな部分だなー。

LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild

すでに公開されてたのでリンクを貼っておく

ElasticsearchとGCPのTCP Keepaliveではまった話 - blog.daich.org

• GCPでの活用事例も今後増えるだろうし、新しいクラウドでのよくはまるFirewall問題の内容だった
• AWSでmulticast discoveryが使えない課題とかを思い出した。。。
• ネットワーク周りの課題はソフトウェアエンジニアからするとちょっと馴染みのないことだったりするのでデバッグの仕方とか改めて参考になった

LT スクリプトフィールドで作るランキングみたいな何か」iwag さん

elasticsearch で作るランキング - SSSSLIDE

• スクリプトは重い、比べたらもちろんプラグインのが軽いんだけど、開発のしやすさでスクリプトを使うのは利用場面ありそう
• Elasticsearchへデータを投入する前にRabbitMQ（メッセージキュー）を使ってリアルタイム性よりはデータの整合性を優先させてた
• スライドの中に出てくるfielddataはES2.x系からはdoc_valueというものが出てきてて下記あたりをちょっと追いかけたいなと思った

www.elastic.co

www.elastic.co

最後・まとめ・感想

• リクルートテクノロジーズさんの階の高いスペースではwimaxが圏外になるので使いえないって前にやったミスを再度やってしまった
  • 次回こそは学習します
• SPEEDAでのESの利用で、約11万フィールドってどうやって管理してるんだろう。。。と思った。
• 1ドキュメントの保存数も驚いたし、そんな手荒い使い方しても普通に動くんだと知れたのは大きかった
  • 自分でも使っててもなかなかそんな場面にならないので
• 次回は懇親会に参加したいな
• 早く自分たちもバージョンあげないと

マクロサービスアーキテクチャを数回読んだ

はじめに

今でも割と語られてるかな？マイクロサービスアーキテクチャを数回は読んだ。まぁそのアウトプットではないが色々と思うところやメモ的なものをここに残しておく

マイクロサービスアーキテクチャ

各章ごとに気になった文や内容を自分なりにまとめていこうと思います

1章：マイクロサービス

まぁマイクロサービスとはいかなるものか的な内容。その中でも今までとは違う点では下記あたりがあるのかなぁと感じた

• より多くの技術的な決断を下さす必要がある点
• すべて正しい決断となるわけではないが、たとえ間違えたとしても影響は局所的になる

2章：進化的アーキテクト

マイクロサービスアーキテクチャに限った事ではないけど、アーキテクトが日進月歩なので変化は激しい。その中で一番気をつけなければいけないのは考え方を固定化させ硬直する事。これは常に自分が間違っているかもしれないという問いを自分自身に問いながら進まなければいけない事を意味する。

スタートアップで事業を立ち上げる立場にある人は割と当たり前だし、その姿勢をシステム設計にも適用しなければならないという事を改めて感じた。

3章：サービスのモデル化方法

• 技術的な概念に基づいたモデリングよりビジネス的なサービスによって境界づけられたモデリングのが適している

またモデリングによる分割が時期尚早な場合が存在する。特にスタートアップ時期ではまた固まりきらない事業フェーズ（ビジネスサイドでよく言うフィジビリ時期）の時とかは注意なのかな

4章：統合

ここは結構内容の重い話が多かったと思う。まずは

1. いかなる代償をはらってもデータベース統合は避ける

今までの経験上、データベースのテーブルスキーマの変更を伴う改修はやっぱり気を使うし、それなりにパワーを消費するのでちょっと避けてる部分があった。でも変化を受け入れ、柔軟に対応する上ではこのあたりも受け入れてやっていかないとなと感じた

でも弊害というかそれぞれで分割されたデータベースを持つということは独立性を高め、変更を恐れなくなるとは思うけど。同じ内容のデータを複数持つことになったり、データベース間で同期をとりたい場合やトランザクションで整合性をとりたい場合はでてくるよなぁー。

そうなると共有のライブラリ(API)でデータの更新や参照するような仕組みは完璧に補えるわけではないけど案として浮かぶ。

このへんは本でも指摘されてるけど今まではDRY（Don't Repeat Yourself）という言葉があるように重複するコードを書くことは必要以上にコードが増え、可読性も落ちて良くないとされてきた。けどマイクロサービスでは同じマイクロサービス単位内ではDRYだけど、別の境界づけられたサービスではokという事だった。

むしろ、結合を産んでしまうので同じライブラリだが、それぞれ独立して持つべきという感じ。１つのマイクロサービスは１つの独立した会社として見た方が腑に落ちるかも

次に

1. オーケストレーションよりコレオグラフィ

音楽で言うところの指揮者がいてオーケストラによる演奏とコレオグラフィ（振付け師）による舞台みたいな対比

少々概念的な話で

• オーケストレーションは、中央の指揮者が他のサービスを呼び出し等を行い処理する動き
• コレオグラフィはそれぞれのサービスが自律的に動き、他のサービスに働きかけていく感じ

まぁSVNとGitみたいな感じかな。でも全てコレオグラフィに寄せることはできないので思考としてそう持つべきという内容と理解

次に

1. ポステルの法則（英語: Postel's law）

ジョン・ポステル - Wikipedia

送信するものに関しては厳密に、受信するものに関しては寛容に

なんかこの言葉だけでとてもしっくりきてしまった。今のAPIを活用したクライアント実装はすでにこれだなと。

5章：モノリス（一枚岩）の分割

ここでも改めて思ったけど、データベースの分割はむずいなーと感じた。サービス（ビジネス）モデルに基づいた分割が全然理解できてないんだろーなー。

本の中でもトランザクションがが必要な時は、キューやログファイルを使い後でリトライの仕組みを裏で幾つか持ち、結果整合性（eventual consistency）で保つことと。。。

むしろお手間な感じがしてしまった。

ここは結構いろいろな意見があるだろうし判断に難しいところなので本でも下記のような言い方をしてた

本当に一貫性を維持したい状態に遭遇したら、まずは分割を避けるためにあらゆる手を尽くします。本当に精一杯やってみてください。本当に分割を進める必要がある場合にはそのプロセスの完全に技術的視点から離れ、トランザクション自体を表す具体的な概念を実際に作成してください

やり尽くした上での選択なんだろう。

あとはデータポンプ、イベントデータポンプといったワードも出てきてETLと呼ばれるような手法も活用すべきだと。

ETLで思い浮かぶのはtalendとかかな。。。

jp.talend.com

6章：デプロイ

ここでは改めて自動化重要性を感じた。インフラのイミュータブルサーバの話から、アプリケーションのビルド、各種自動テスト等々本当にどれもスキップできない構成がある中で効率的に且つ何度も回す必要があると。

7章：テスト

まずはモックとスタブの違いはわかりづらく、ここをしっかり抑える必要がる。

• モックとは

  • ユーザーインターフェイスの振る舞いを模倣したもの。。。。個人的な理解でいうと、例えばPHPUnitでgetMockBuilderというメソッドがある。まぁこの振る舞いをモックと理解している getMockBuilder

• スタブとは

  • テスト時の呼び出し時にあらかじめ用意された結果を返す。通常はテスト用にプログラムされたところ以外では使わない。接続先のサービス(API)のインターフェースが変われは追随する必要がある

原文を一応あげておくけどMartin Fowlerの説明はちょっと分かり難い？英語の問題もあるけど。 martinfowler.com

必然的に疎結合が多くなるのでテスト時はスタブ化してテストしてくことは必須でThoughtWorks社から便利なツールが色々ある様子

あとはE2Eテストの存在がある。今のチームでもE2EテストではCapybaraを試してみてるが、やはりメンテコストが結構かかる。でもやらないわけにはいかないし、メンテして1日終わってしまう事もある。

ここで初めて複数のチームが共有所有する事がベストプラクティスではないかとある。今まで独立性、自律性に重きを置いた思考であったが、E2Eテストに関しはちょっと違う。

次に

• カナリアリリース

ここは具体的な方法をもっと知りたいなぁー。会社によって色々とやり方あり出し。そーいやリーンスタートアップってゆう本にもこのワード出てきてた。

リーン・スタートアップ

• MTBFとMTTRのトレードオフの理解

すべて完璧な状態でリリースは結構難しくて、平均故障間隔と平均修復時間のメトリックスを気にしながら絶妙なバランスが必要。そのサービスが担う役割によって当然話は変わってくるけど基本的にこのトレードオフの関係を理解しておくこと

8章：監視

• 相関IDを活用

サービスの疎結合と高凝集性があるので障害・不具合が出てきた時に追いかけて、特定しづらくなる。そこで相関IDを活用して効率化を図る

• 合成監視

一般的なCPUやメモリのメトリックではわからない。偽イベントを生じさせてそこから得られる結果からシステムが正常に稼動しているかを推し量る考え方でセマンティック監視とも呼ばれるみたいです。この観点は今まであまりなかったのでプロダクトに生かしたいなと。

9章：セキュリティ

境界内のアクセスに対するセキュリティはほぼなく、暗黙的に信頼のもとにできている

ここで出てくるセキュリティの項目は割と一般的な項目であり、様々な役割のサービスごとに最適なセキュリティ対策を実施すべし。ですべてにおいて厳しいセキュリティ項目を設けなくとても良い。

• 間違っても自分で暗号化実装をしてはならぬ

間違っても手を出しません。

10章：コンウェイの法則とシステム設計

ここはなかなか重い話だなぁ。結局はソフトウェアは人が作るし、運用していくのは人、組織であるからコンウェイの法則はまぁその通りと思う

でも逆向きのコンウェイの法則の話があったけど、業態のパラダイムシフトが必須の状態が追い風となってると思う。こう言ったものがセットでないとなかなか厳しいなぁと感じた。

会社によってシステムアーキテクチャがどの程度の発言権があるかによるが、日本の場合は当事者がファンダーとかでない限り、この考えを浸透させるのは厳しいだろうな。

システムアーキテクトと組織構造がセットで、その２つを一致させないとツライという話。。。想像しただけでもツライよね。

11章：大規模なマイクロサービス

• Swaggerの話が出てきてふと社内勉強会の内容を思い出した。下記です。ちょっと点が繋がった

Swagger 入門 from Yoshiaki Yoshida

www.slideshare.net

• CAP定義

整合性（consistency）、可用性（availability）、分断耐性（partition tolerance）があり、トレードオフの関係値になっている。頭文字をとってAP,CPシステムという感じになりケースバイケースで判断していく

本書を読んでのまとめ・感想的なもの

• 何度読み返したかわからないけど、今回この本を読んで残ったものはコンウェイの法則,DBの分割(整合性の分割)の部分かなぁ。ムズすぎ。
• DBの分割はコストもかかるし、かなり慎重にすべきだなぁー
• 会社ってどこもセールスの人がいてそれなりの営業的な文化がある
  • よくその文化の中の文脈で一枚岩というワードが出てきてone for all的にチームとして頑張ろうという流れがある。別に普通に賛成なんだが、たまにその事がモノリスの弊害のようになってて、逆に効率が悪いというかってゆう場面を思い返した。協調性がないって思われそうだから何も言えないけど。そーゆー落とし穴は誰かが気をつけなければいけない。
• 自律的なチームはまさにそうで、専門性をどんどん高めていかないといけないし、どうしてもモクモクとやる姿が多くなっちゃうよなー
• 他の手法、考え方でもそうだけど、決して銀の弾丸ではない

Skyland Ventures Meetup #19 スタートアップのOKRの運用と組織作りとは に参加してきた

勉強会概要

svmeetup.connpass.com

そもそもOKRとは？

下記あたりの説明を読むとわかりやすいです

hiromaeda.com

library.gv.com

ゲスト講演+セッション+Q&A

エンジェル投資家 山岸 延好氏(元クックパッドCOO)さん

• 社員が10名〜30名、30名〜60名の時の採用の話や組織作りのお話
• 創業当時からエンジニアの採用にはlimit無しで力を入れていて、今もそうだなとは外から見ても感じる
• 社員数が50名ほどになったあたりからORKを導入したらしい

OKRとはちょっとずれるかもしれないが興味深かったのは下記の項目

• 事業の成長に個人の成長が追いつかなくなり、途中でミドルマネージメント層の採用に力をいれた話
• 社長ではなく、役員全員が話をする週一全体会議（全社員参加）の話
• 査定などの評価を伝える時、それはその人に発するメッセージである。
  • 必ずしも被評価者が納得しないパターンは多くあり、明らかに不満が多く納得できていないことは多くあった。
  • そこに対する対処は未だに試行錯誤という感じであった

メルカリ取締役小泉氏

メルカリの半数はカスタマーサポートでカスタマーサポートを抜かすと約130人程度の人数らしいです

ミッションとバリューの決め

役員だけでミッションとバリューを決める合宿をし5年、10年後のプロダクトのゴールを強烈にイメージして決めた

組織(文化)作り

• Plan

  • バリューを軸に性善説に則り、ネーミング、パッケージ化にこだわって企画を練る

• Action

  • プレゼンしメンバーを巻き込む
  • メンバーが施策をコミットし発信する

• Review

  • 発信後の社内外の空気感をチェックし、利用されてない＆しらけている場合はすぐにやめる or チューニングを実施

人事評価と処遇

下記の項目で行っている様子

• コミットメント評価（OKR評価）
  • プロダクトを成長させる為に基本的に設ける
• バリュー評価
  • OKRでは拾えない、突発的な仕事やトラブル対応などはここで評価
• スペシャリスト評価
  • 技術的なスペシャリスト枠をしっかり用意し、マネージャとは違うキャリアパスを用意

OKR

• OKRとはいわば、会社でやっていく優先順位と同じであると。
  • 目標と期待されている結果を明確に設定することで「何をフォーカスするのか」、逆に「何を無視しても良いのか」をクリアに
• MBO(management by objectives)とよく比較されるが、OKRはほぼ優先順位として考えているのでMBOにある網羅性はOKRにはない

OKRを運用する上でのポイント

• OKRはツリー型なので会社全体のOKRがあって、そこからブレイクダウンする
  • たとえどんな部署（職種）であっても、適用は可能だし、それを見つけてあげることが重要
  • 上からブレイクダウンされるので自身のOKR達成が、上司のOKR達成に寄与する
• Objectiveには必ずしも定量的である必要ない、Key Resultの部分で1〜4つ程度の定量的なものを入れると良い
• 3ヶ月を一区切りとして1.5ヶ月を過ぎたところで中間チェックとして上長との面談を実施
  • 面談を半ば強制的に行うことで話さざるおえない状況にする
  • 定期的な面談は強制的なコミュニケーション時間
  • 6ヶ月では環境変化に対応できない
• OKR以外の突発的な対応はバリューの基準で評価してあげる
  • メルカリのバリューは「Go Bold – 大胆にやろう」「All for One – 全ては成功のために」「Be Professional – プロフェッショナルであれ」
• 全社員へオープン。全員に見えるように
• 毎日OKRの進捗確認をする
• 組織変化、状況変化が激しいのでフレキシブルに対応する
• ほぼすべてのOKRを絶妙な高さ（難易度）に設定することが重要
  • 高すぎても疲弊するだけ、低すぎても成長がない

おまけ

• メルカリでは承認会議はほぼない
• ABテスト等ならエンジニア判断でリリースさせる自由度がある

と言った感じで自由度、スピード感もある

まとめ・雑感

• やっぱり、大きな目標を達成させるには個人だけでは到底無理だし、チームとして戦うことは前提。こんなことは言われないでも分かるでしょとなりそうだけどまぁ基本に立ち返るという意味で改めて。
  • でも最近は all for one的な気持ちは皆当然あるし、やってるけど、それだけでは高い目標に達することは厳しいと感じてて。。プラスアルファで自分の得意分野（武器）を鍛え、発揮していかないと目標に届かないなーと。
• OKRで全て事足りることはなく、その他イレギュラーな必要な業務を行ってくれた所には別軸（バリュー）で評価をしてあげ、拾ってあげる。これはなるほどーって思った。
• 今の会社でも目標設定シートは存在するし、似ている箇所も多く存在するが、個人の目標(OKR)を会社全体に公開して全員で共有することはいいなと感じた。
• 一応、自分の今季のOKRは公開しているけどもっとアピールしようかな
• 自分のOKR見直さなければ。

Neo4j ユーザー勉強会 #7 に参加してきた

勉強会概要

jp-neo4j-usersgroup.connpass.com

はじめに

扱ってるデータが今話題のパナマ文書なだけに資料はアップされないし、この勉強会中の写真等のアップはお控えください。だったので自分も控えつつ、技術の内容を中心にまとめる事とする

発表

Graph Connect Europe (2016/4/26 於：ロンドン開催）イベント報告

パナマ文書の概要

• もともとはパナマにある法律事務所のモサック・フォンセカから出た機密文章
• ドイツの新聞社がはじめこの機密文書を解析を試みたが、莫大なデータ量(2.6TB)で解析できず、国際調査報道ジャーナリスト連合 (ICIJ)が協力してデータの解析することとなったらしい

詳しくはwikiで

パナマ文書 - Wikipedia

ちなみにICIJは過去にもoffshore leaks,china leaksといったものも解析してみたらしいです。 で今回過去に例のない莫大なデータ量(2.6TB)のデータ解析にNeo4jを活用してる為に今回の勉強会のテーマになった様子

ICIJには結構人数はいるそうですが、今回解析したエンジニアは実質３人のエンジニアがやったらしいです。

じゃ3人でどのようにやったかでいうと

• 元々データはEmail 41% database 26% 残り紙等の非データ化のデータ
  • 非文字データ化がまだまだ多いらしく、人力が必要でこれからまた新しい情報も出てくる可能性は高いらしい
  • 下記に詳しく載ってる panamapapers.sueddeutsche.de
• 約40台ほどのawsのインスタンスに
• Apache Tikaでメタデータを取得して
• データベースからはtalendを使ってNeo4jに入れて
• Solaを使って検索して
• Linkuriousで可視化して

等々を駆使してやっているらしいです。このあたりで出てきてるワードで調べていけば何となくアプローチ方法はわかりそう。。。

ちなみにパナマ文書以前は

• SQLサーバでSigma.jsでグラフにしてやってたらしい
• 今回これだとデータ量的に全く追いつけないということでNeo4jを活用したという流れ

Neo4j v3.0の紹介

今回の紹介で気になったのをピックアップ

• Improved Cost-based Optimizer
  • 以前 read = cost base,write = rule base
  • 今回 read = cost base,write = cost base
• Official Language Drivers & Bolt
  • JavaやJavaScript,Pythonなどの主要な言語でドライバが公式にサポートされた点
  • Boltというバイナリ通信プロトコルをサポート。全然知らない、、、勉強せねば
• Java stored procedure
• spatial function
  • 今後使い勝手が増すようなきがする
• Neo4j Browser Sync
• githubとかのアカウントでログインできる

パナマ文書分析アプリの開発過程の紹介（ドキュメント集取から分析可能なデータモデルの構築、アプリ開発まで）

データにある直接的な関連付け(relation)とデータから読み解いて間接的にわかる関連付け(relation)がある。 この後者の間接的な関連性が重要らしい

間接的な関連性とは

例えば、人というノードのプロパティに住所情報がある場合、同じ住所情報のあるノード=人は一緒に住んでいるので家族である可能性が高い等々

いずれにしてもまだまだデータを解析が終わってる段階ではなく、下記の3つの観点で解析を進めている様子

• データ化されてないもののデータ化
• 他の国の情報（国勢調査情報、警戒リスト）を参照してデータのつながりを作成
• 企業活動（お金の流れ）データの取り込み

PDF等のデータ化されていないものはどうしても人力が必要らしく、今後数年をかけてデータ化して解析してくらしいです

Talendを使ったパナマ文書のETL処理

技術的な紹介はあまりなく、事例等々の紹介がメイン

5/9に公開されたパナマ文書データベースを使ったデモ

これ、ほぼ言える内容ではないですが、一番やはり面白かった？やばかった。

技術的な事でいうと

• プロパティの値はdiskに乗っていて、ノード、ノード間のリレーション、インデックスはメモリに乗って稼動する
• なのではじめに適当に下記のようなクエリーを投げるとメモリに乗って早くなる match(n)-[r]-() return count(*)
• Neo4jの内部はLuceneを使われてるらしくwhere句に=~が活用できて便利

まとめ的なもの

• Neo4j v3.0の紹介は下記あたりで一通り見れる neo4j.com
• やはりデータとデータの関連付けが重要でこの部分をどうやるかで結果もだいぶ変わってくるなぁと感じた
• 周辺技術（Apache Tika,Talend,Linkurious等々）も重要でこの当たりも見ていかないとな
• ICIJのサイトからパナマ文書の一部をダウンロード可能らしい
  • 今回のデモはこのデータを使ってた
  • データ検索とかは下記で可能 https://offshoreleaks.icij.org/offshoreleaks.icij.org
    • Offshore Leaksというデータに今回のパナマ文書が一緒になってる
  • ダウンロードはhttps://offshoreleaks.icij.org/pages/databaseで
    • CSVやNeo4jの形式でダウンロード可能

dots.スタートアップ部 の勉強会に参加してきた

月に2回程度のペースで行っている外部勉強会の公開メモ

勉強会概要

eventdots.jp

発表

ロカリを支える技術　@TakashiChi_ba さん

• ”便利なもの”は作らないうにしよう
• 届けた価値だけを評価。
  • それまでの過程の努力とかを評価対象にすると全員が苦労しているのでお情けの評価になってしまうのでやめよう
  • ユーザに届ける価値（機能とか）が評価対象なのでインフラ面等々はほぼ全て外部サービスをできるだけ活用してユーザに届ける昨日開発に集中する
• 自社の広告サーバーがあったり、解析系にもやられていて全体的にパランスよく整えてる感じだった

日本から世界へ 〜食 × テクノロジースタートアップ企業の軌跡〜 樽石さん

• Dogfood文化いいなー
• ElasticBeansTalkを活用したdeploy
• とにかく失敗しまくろう＝リリースは毎日。驚異のリリース回数
  • 高速PDCAを回すにはAWSだけでは無理
  • スタートアップの最大の武器はスピード。それを最大限利用することが一番大事
  • １つのクラウド業者だけでは限界がある
• 機械学習マシン(GPUクラスタ)を社内においてやることで非エンジニアも興味を持ち、見える化すると頑張ってる感出る

会社になることがわかっていたら… @佐野 さん

• 初期の構成の話を聞くと本当に個人の開発環境みたいな感じだった
  • お題の通り、仕事としてプロダクトを作ると最初から分かっていたらという
• 数億レベルの売り上げに至るまで一人でやられていたのだからすごい。

Docker in Production @toshitanian さん

• 解析エンジンをdockerコンテナを使い、コンテナ数1万以上。
• 解析をしやすく、開発をしやすく、運用コストを下げる為Docker
  • 本番のプロダクションだけでなく、開発環境をすぐに作るといった部分でもDockerは便利でいいなーと思った
• 画像解析の部分に個人的に興味がわいた
• 扱うデータ量も一番多いと思ったので、軽量化はスピードはとても重要なんだろうなと感じた

今だから言えるやらないほうが良かったこと @threetreeslight さん

今だから言えるやらないほうが良かったこと from Akira Miki

www.slideshare.net

• 経験という名の失敗
• 機能ごとに別市場
• 磨く時間がちょーだいじ
• 役割分担としてしっかり定義して、エンジニアはコードに向き合う時間を確保することが重要
• 昔作ったけど今は使われていない的な機能はうちもいっぱいある。。。
• 現場満載で個人的にはすごく共感できたし面白かった

まとめ的なもの。感想

• 本来使うべきところにちゃんと時間を使えるように自動化できる部分は自動化させておくことは重要
  • そうでないと時間を使って考えなきゃいけない設計等々に時間が使えず、常にルーティン作業やトラブルシュートに一番時間投資をすることになる
  • 働く時間は長くなるので頑張ってる感は出るが、本来やるべき重要なことはできないので結局よくない
  • その意味でも開発周辺の外部サービス（circle ci / awsの各種サービス）は存分に活用すべき
• 密かにあった直面する課題として対人の問題ってあるなぁ。

成功への情熱_稲森和夫

成功への情熱―PASSION

 

• 全端的な感想

社内の意識改革、価値観、文化を形成する為の勉強会・講習会の資料を元にされた本であり、かつ米国向けのグループ会社向けに作られた資料を再度翻訳されたものだけあって非常に分かりやすい言葉で書いてある。

私が心に残った言葉としては下記の２つある

「人生の結果＝考え方x熱意x能力」

「信頼とは外に求めるのでは無く、自らの内に求めるものである」

なぜこの２つの言葉がいくつもある中で心に残ったのかを考えると無意識のうちにこれらを課題だと思っており解決へのヒントになると思ったからだと思う。

前者はこれまでのこれと誇れる成果を残せていない自身への課題であるし、後者はチームとして戦うために必須の要素の信頼という目に見えないもおをどのように備えるかという課題である。

考え抜く一つの突破口にしようと。

ちょっと偉そうに自身の考えも書いてみる。。。

• 問題提起

マネージャなどの管理職に値する人材にはとても良い資料となっているが、会社として成果を上げるには管理職だけでなく、その下で働く一般の授業員も一つにまとまるような施策が必要になる。

管理職の人材は言うまでもなく重要な要素だが、その下で働く従業員は数でいうとはるかに多く、彼らに対する訴え（教育）の方がむしろ重要なのではないか

• 意見提示

一般の従業員をまとめるためにまず、管理職の人材にこのような訴え（教育）を行うというのだ。

とすぐに言われそうだが、縦割りの組織の考え方としては確かにそうである。

私が思う事、言いたいことは

組織のトップ（トップに近い人材）からどんなに簡単で単純なもので良いので直接一般の従業員に向けたメッセージを発する事が全体の組織としてむしろ、合理的であり、効果的であり、且つ難なく今すぐ出来る事なので、それをセットでやるべき。ということである

• 結論

会社の永続的な反映としては管理職以上の経営者層のベースアップはもちろん必須であるし、重要であることは間違いないと思う。

しかし、会社として共通の価値観や文化を兼ね備える事をも目的としているならば（読解力がなくスイマセン）上記の方法も取り組むべきかもしれない。