API Meetup Tokyo #8 〜FinTechとAPI〜
SMBのバックオフィス業務を最適化するAPI連携
freee 藤崎さん
- @fuki_tip
- 某製造業の研究所の社内SEから転職
- freee('13 2~)ではマーケティング、パートナーアライアンス、プロダクト連携
freeeの紹介
- 「スモールビジネスに関わるみんなが創造的な活動にフォーカスできるよう」
- 今取締役はほぼex-Google勢
- 従業員100+
従来の請求書受領〜支払の事務はとても煩雑
- 同じ情報を何度も入力しないといけない非効率さ
- スモールビジネス向けクラウドサービスが増えている
- NRI調べによると、クラウドサービス利用企業の労働生産性は9ポイントほど高い傾向
- クラウドシフトによる経済効果は5.9兆円
API連携の推進
- freeeは'13 10月(2万事業所の時期)からAPIを公開
- 現在は30万↑事業所
- スクレイピングと違い、API連携は破綻しにくい
- API連携の例
- POSレジ
- ユビレジ
- Airレジ
- 日々のレジ売上が簡単に計上できるように
- 「売上の記帳が0秒になりました」という事例も
- クレジットカード決済
- Square
- Coiney
- 管理画面上の集計をAPI経由でカード売上、決済手数料
- 銀行口座へ入金されるにあたっての手数料分の差し引きなども正しい値で取れる
- ECショップ
- BASE
- Y!ショッピング
- EC売上、支払いケースごとの決済手数料、そのほかの手数料
- 帳票の電子保存
- ScanSnapのS-cloud
- 読み取ったドキュメントを読み取って自動でサービスにpush
- A4プリントはGoogle Docs、名刺はeight...など
- 帳票をfreeeにpushする連携も
- 金額、日付や勘定科目をOCRで自動入力
- 読み取ったドキュメントを読み取って自動でサービスにpush
- ScanSnapのS-cloud
- POSレジ
バックオフィス業務をクラウド上におくことで、自動化・バックオフィス最適化が進んだ
今年の動き
クラウド完結型社会
- 認証さえ組めば、情報の再利用が簡単に可能になる世界
- リリースから半年でAPI公開、外部から叩いてもらうことで再利用を強く推進してきた
Q&A
- ドメスティックなサービス、スケールは契約数なのかなと思う
- 政府に向けてのロビー活動みたいなものってやってます？
- 日本特有のサービスである一方、パートナーとの連携の間で気にかけていることはあるか
- 日本のスモールビジネスに一番詳しい、という自負がある
- 市場にアウトプットしていこう、という意気込み
- そのアウトプットが良い形に転がることを期待してる部分もある
- 日本のスモールビジネスに一番詳しい、という自負がある
- 今後おもしろそうなAPIはありますか
- セキュリティって
- オンラインバンキングのID/passはFWの向こう、ネットワークに繋がらない場所にストアしている
- 法人決算情報については最終的にパブリックになるものなのでSMBなら神経質になりすぎなくてもいいのかな、という印象
- セキュリティに関する説明をし終えて、懸念されるユーザーはやはりいて、ロストしている顧客はやはり一部ありそう
- 100%は不可能、おそらくこのリスクはクラウドサービス全般が負っているものだと思う
- 大企業向けは？
- 今のところ狙うつもりはない
- レイテンシが主な原因、技術的に可能になるかもしれないが...
- 今のところ狙うつもりはない
PayPal APIで紐解く決済の仕組みとこれから
PayPal 岡村さん
- @benzookapi
- Scala, Java, Ruby, JS, PHP, Powerpoint
- Integration Manager
- この3月からjoin
BattleHack Tokyo
PayPalとは
- ネット上の財布を建てて、ネット上でお買い物してもらう
- 日本では銀行口座を直接後ろに建てることは出来ない
- 売り手に直接クレジットカード情報を渡さず、アカウントに隠蔽した状態でやりとり
- 売り手・買い手両方への保護、システムと24365監視
- 1.6億アクティブアカウント、26兆の流通額
- 50%以上が国際取引、26通貨に対応
国内の利用会社はfreee同様、スモールビジネスのプレイヤーが多い傾向
-
- ピーター・ティール "Zero to One"著者
- イーロン・マスク
決済について
-
- PayPal APIの種類
- 通常決済(Checkout)
- 定期決済(Recurring Payment)
- 事前承認をもとに決済を定期的に繰り返す
- 月額会費制サービスなど
- 定期決済の成功、失敗はPayPalから通知を受け取る
- 無料期間なども対応可
- 任意決済(Reference Transaction)
- 事前承認を元に任意のタイミングで決済する
- ゲーム課金、動画月額支払など
- プリペイド的な使い方
- 売り手の自由度が高い強力な決済、別途審査が必要
- 通常決済とほぼ同等のパラメータが使用可能
- 連鎖支払(Chained Payment)
- 一括支払い
- Sale/Auth/Cap/Order
- Sale: その場で支払い完了
- Auth+Cap的なやつ
- Auth(orization): クレカなどの与信だけ取る
- Cap(ture): 与信をもとにした支払い完了
- Order: PayPalアカウントの確認のみ
- 注文時にAuthして配送時にCapなど
- Sale: その場で支払い完了
使いたくなったでしょ？
- Sandbox!
- 支払い・受け取りし放題！
- サービスが儲かっている妄想ができる！
海外の新サービスと決済のこれから
- US PayPalのサービス
- 日本の決済のこれから
- Q&A
- PayPal APIを叩くクライアント側で気をつけることは？
- クライアントになるのは売り手側、FB/TwのOAuthのように代理で叩くような窓口はほぼない
- 「Login with PayPal」という似たようなやつはあるが...
- ただただ売り手側の決済を叩く、というのが実態なので、やりとりとしてはトークンの交換で完結する
- やりとりする情報自体は絞られている
- リダイレクト先のパラメータが完全一致してないとエラー、など、そのあたりはガチガチ
- 逆にサーバ間で認証が完結するので、RESTに準拠している分のセキュリティはまず担保している
- クライアントになるのは売り手側、FB/TwのOAuthのように代理で叩くような窓口はほぼない
- 可用性をビジネス的にどうネゴシエーションしている？間違ったアプリ側のリクエストに対するフェイルセーフは？
- 傾向から分析してシステムに落としたり、人材の傾向はあるか？
- 不正(fraud)の積み上げは社内であるし、セキュリティの会社を買収していたりもする
- BrainTreeはそのあたりのエンジンがある
- 人材としてはコンプライアンスの世界の人が多い、お金を扱ってきた人
- 不正(fraud)の積み上げは社内であるし、セキュリティの会社を買収していたりもする
- PayPal APIを叩くクライアント側で気をつけることは？
Banking API and API Ecosystem
藤井達人さん
銀行系のAPIがどういう可能性を持ってそうか、といったところを個人的な見解も含めて
伝統的な金融業界は宇宙人に攻め入られている
- Disruption
- 銀行の三大業務
- 預金
- Y-DLEE, Levelmoney, Geezeo, ...
- 為替
- stripe, ...
- 融資
- Lendinglob...
- 預金
- このへんのFinTech組み合わせたら銀行できちゃうのでは？？？
- Open Architecture POSをGoogleの人たちが組み上げちゃったりしてる事例もある
Banking APIとは
- Retail Banking APIs
- 一般
- 口座開設、残高照会など
- Commercial Banking APIs
- 法人
- 企業のキャッシュマネジメントシステムやFX,EDIなどへの連携
- Internal APIs
- 内部
- 社内の開発効率アップのためのAPI
- Retail Banking APIs
- Banking APIは、ガートナー社のハイプ・サイクルにも登場
事例
- Citi Mobile Challenge
- Credit Agricole
- フランス最大の銀行、ヨーロッパトップ２
- 運営しているCA STOREで認証されたアプリはCredit AgricoleのAPIを叩ける
- リテール系のAPIをヘルスケアと組み合わせたり、などなど
- わりと変なアプリもある
- Barclays
- Capital One
- アメリカ大手
- もともとクレジットで大手、加盟店のユーザーへのレコメンデーション・ポイント付与のためのエンジン・APIを提供
- Capital Oneはかなりエッジなことが好きな銀行
- ハワイのCapital One 360 Cafeでアイス食べながら銀行員にお金の相談したり、
何が目的か？
- イギリスではBanking APIの標準化が進められようとしている
- ロンドンとNYは世界で一番FinTechで勢いがある場所
- イギリスは政府レベルでFinTechで推進、オーピンデータのビジネス化の一環
- 英政府の銀行口座ポータビリティ制度、しかしあまり使われてない
- 金融商品や顧客サービスに対する透明性に不信感が有るためのよう
- そこの透明性を高めていこう、という機運がある
- Banking APIを使うと何が出来るのか？
銀行サイドでは？
まとめ
Spark Casual Talk #1
Spark Casual Talk #1 - connpass
- 敷居を下げるためにカジュアルとつけたけど、LTのラインナップを見るにかなりガチですね
- Sparkなんで既定路線ということで
Spark Summit 2015 参加報告
- @potix2
- 神田さん
- CAアドテク本部 AMoAd
- OS/分散システム専門でやってます
- 毎月Lispのミートアップもやってます
- Sparkと私
- 広告のデータ分析基盤としてのSpark
- 業務とは離れるけど、社内の研究支援制度でSparkゼミをやっている
- 業務でやってるならSparkにコントリビュートしよう、という感じで
- ソースリーディングやIssuesやPR上げたりをもくもくとやっている
- Sparkとは
- Sparkユーザは会場に半分くらい
- 高速な汎用計算エンジン
- メモリにキャッシュするので繰り返し計算に強い
- ロジスティック回帰は100倍早いです、というよくある謳い文句
- うそ臭いなあといつも思うのですが出しておく
- コンポーネント
- Spark core
- Spark SQL
- MLlib
- GraphX
- 最近あんまり活発でない、ですが、Spark Summitでは事例が出てました
- Spark Streaming
- リアルタイム処理ライブラリ
- Spark core
- Sparkを取り巻くエコシステム
- YARN、Mesos
- YARNの方がメジャー、Mesosは実装が足りなかったりする
- 最近Dockerでも動くようにサポートされました(1.4~)
- YARN、Mesos
- コミュニティも成長を続けている
- 1年でコントリビューターが255人から730に
- コード量も175kから400kに
- 大丈夫かな、と思いつつ、コアはあんまり膨れてないらしい
- 「IBMがApache Sparkプロジェクトに3500名を投入」
- 最近のリリース
- 6月に1.4、3月に1.3
- 1.3のDataFrame APIがとても大きい、のでここで触れておきます
- 6月に1.4、3月に1.3
- DataFrame API
Spark Summit 2015 振り返り
- 先週6/15~17
- データ分析に関わる内容が多かった
- データ分析基盤としての活用事例が多い
- 「Baiduでは8000ノード使っています」みたいな
- MLlib活用して予測モデルを建てたり、といった事例がたくさん
- 先進的な事例が多いので、性能改善がコミュニティ内部での優先度高に
- 出自が出自(大学の研究室)なので、産学連携しながらコミュニティが成長している
- アカデミックな雰囲気も有るカンファレンスでした
SparkSQL/DataFrameAPI関連
- DataFrame APIチュートリアル
- Spark DataFrames: Simple and Fast Analysis of ....
- おそらく今週くらいにSpark Summit公式にスライドが上がってきます、もうちょっとして動画も
パフォーマンス向上関連
- 今回喋りたいトコ
- Making Sense of Spark Performance
- How to Boost 100x Performance for Real World Application w/ Apache Spark
- Intel上海チームのSpark性能改善タスクの共有
- プロジェクトTungsten
まとめ
- DataFrame API, Spark SQLなどデータ分析の基盤となる機能は継続して開発
- データ分析基盤として活用するユーザー企業が増えている
性能改善へのニーズが増してきている
Q&A
- 英語はペラペラなんですか？
- 全然ダメで、MeetUpでも質問してみたけどボロボロでした
- DataFrameAPIはテーブル型なのでMLやGraphXとは関連しない？TungstenはDataFrameAPIに特化したプロジェクト？
- CAではSparkはどう使っていく？
- ウチ(AMoAd)では分析基盤、別の場所ではストリーミング
- 規模感としては共通基盤はないので、チームごと・PJ単位でアドホック的に気軽に使う程度、今後変わるかも
- CPUボトルネックで困ってる、みたいなケースはある？
- CAではまだない
- モダンなハードウェアでDataFrameをガチガチに使い込んで初めてCPUボトルネックが見えてくる、という領域だと思います
- SSD24個とか、10GNWとか
- 英語はペラペラなんですか？
メキメキ開発の進むApache Sparkのいまとこれから
- NTTデータ土橋さん、猿田さん
- 猿田さん
- 6月Sparkコミッタに就任
- コアエンジニアに近い立場、dev寄り
- 土橋さん
- 去年Spark Summit '14で事例紹介しました
- OSSを使い倒すチーム、ユーザー寄り
- 猿田さん
Spark開発の最前線(猿田)
- '14とくらべても非常にドラスティックに変わっている
- ざっくりおさらい、Apache Spark
- 1.3.0までのホットトピックをおさらい、1.4.0のホットトピックをキャッチアップ
- 従来のMapReduceが苦手なスループットとレイテンシの両立が領域にアプローチするためのプロダクト、そのうち最も早く商用に載ったもの
- Sparkの全体像
- 1.3までのホットトピック
始めようSpark(土橋)
- 今から使うならどう使う？
- スキーマレスデータはRDD、構造化データはDataFrame
- 今は連携できるので、うまい方を使いながら組み合わせられる
- 去年までは統計処理が多めだが、今年はストリーム処理・機械学習との連携が多かった
- MLlibは「分散処理の恩恵を受けられるアルゴリズムを実装する」という方針だが、定番アルゴはまずまずの充実度
- 細かいところが足りない、と思ったら積極的にコミュニティに意見しましょう
- MLlibは「分散処理の恩恵を受けられるアルゴリズムを実装する」という方針だが、定番アルゴはまずまずの充実度
- DataFrameほか、いろんなデータソースを意識するように
- センサデータみたいなものも取り込めるように
- 構造が異なるデータも柔軟に扱える
- 大規模データでの動作もだいぶ安定していた
- ちょっと前はメモリに全部ぶち込んでたので不安があった
- スキーマレスデータはRDD、構造化データはDataFrame
- 気に留めておきたいこと
- Sparkを動かしてみよう
- Zeppelinと一緒にSparkの簡単な動作を紹介
- Apache Zeppelin
- Mathematicaみたいなノートブック
- のんびり開発中、コントリビューター募集中
- Apache Zeppelin
- DataFrame入門
- 定期預金契約に関するサンプルデータを読んで、Sparkで処理
- デモ:
spark-csvを利用して、DataFrameAPIで特定カラム抜き出し、Zeppelinでグラフ化 - spark-shellでもzeppelinでもMavenパッケージをそのまま使えます
%dep z.load("...")spark-shell --packages
sqlContextでcsvをSQLっぽく読む(DataFrame型).selectで抽出したDataFrame型に
%sqlでSparkSQL文で解釈して、Zeppelin組み込みのグラフ表示までやってくれる- バックエンドでデバッグするだけでなく、SparkのWebUIから参照できるので
RDDとMLlibの事例は興味があれば
- スマホのジャイロで座ってるのか、立ってるのかを当てるデモ
まとめ
- 後方互換性をかなり保ちながらも、1.2以降ドラスティックに変わってきています
- 動かすこと自体は難しくないので、ちょっと気になったら公式quickstartが詳しめ
- 本気で使う方は開発現場を盛り上げていきましょう
Q&A
- iPython系もSpark使えた気がするのですが、シェア的にはどっちが多い？(→土橋)
- keyの偏りみたいなものをなんとかするコツはありますか？(→猿田)
- Sparkは分析をメインにしていく、というイメージ？前処理の部分もこれまで通りやっていく？(→土橋)
- 「前処理にもパワーや試行錯誤が必要です」というケースがたくさん出てきている
- どの説明変数が効果的か、というような、前処理とアルゴリズムの選択を一緒くたにできるのがSparkの嬉しいところ
LT
SparkSQLの構文解析
- @iyunoriue
- CA
sqlContext.sql("SELECT * FROM records")
Run Streaming + Amazon Kinesis
- @imai_factory
- Amazon
- 前職では広告配信サーバに携わったりしてました
- SparkStreamingのいいところ
- DStream
- Amazon Kinesis
- フルマネージドなストリームサービス/メッセージブローカー
- 怒られちゃうけど平たく言うとフルマネージドKafkaみたいなやつです
- Kinesisのストリームにウィンドウ関数/SparkSQLする
- Kinesisバックエンドの実装
- td経由のjson→Kinesis→Spark
KinesisUtils.createStreamのDstreamをunion、foreachRDDしてgroupBy
- EMR上でもSparkが一撃化しました
- 最新ではなく
1.3.1なので注意
- 最新ではなく
ML Pipelineで実践機械学習
- 谷口さん
- 機械学習の流れ
- Training Data
- with (label, ...)
- Feature Engineering
- 特徴抽出
- Machine Learning
- 学習
- Prediction
- 予測
- Training Data
- ML Pipeline
- DataFrame -> Pipeline -> Pipeline -> Modelの流れ
- Logistics回帰の例
- アルゴリズムを変える、みたいなところでも一箇所変えるだけでよい
アドホック分析で活躍するApache Spark
- @moyomot_
- Gunosy
- 森本さん
- 一言で言うと
- サクッとSparkを試すにはEMRがオススメ
- Gunosyのデータ分析の主軸はRedShift
- RedShiftに無いデータを分析するところでSparkが出てくる
- 日々追加する中で、Redshiftにないデータを一時的に集計するとき、など
- Sparkのここが嬉しい
- S3との親和性が高い
- JSON取り出しが容易
- SparkSQL、DataFrameが使える
分散基盤の運用は大変
- そこでEMRです
- 先週正式サポートされました
ホントにカジュアルなネタを用意してきたのですが、違ったのかなあという気がしています
HUE NOTEBOOK
- @kernel023
- Cloudera
- Tatsuo Kawasaki
- インストラクター
- 今日はYARNを２時間くらい喋ってました
- 今日言いたかったこと
- 『ラーニングSpark』日本語版が8月か9月に出ます
- 翻訳は象本でおなじみの玉川さん
- 『ラーニングSpark』日本語版が8月か9月に出ます
- Jupiter、Zeppelinみたいなものがもう一つあるのでこれを...
- Hue
- ふえじゃないです
- Hadoop User Experience
- Hue以前はパワーユーザーがコマンドラインで分析してました
- Hueからならブラウザ経由でカジュアルに叩けます
- Zeppelinとおなじくノートブックで使えるようになりました
- iPython, Zeppelin, Jupiterなどが有名ですが
- HueはEMRバンドルなので、じきにデフォルトで使えるようになるかも
Dynamic Resource Allocation on YARN
- YARN
- リソースマネージャの実装
- Sparkの話だったんですが、YARNを使うとMapReduce使ってるリソースをそのまま使えるようになります
- YARN overview
- すべてのリソースを知っているResourceManager
- いくつかのNodeManagerに仕事を振っていく
- Spark on YARN
- yarn-cluster mode
- SparkのマスターをNodeManagerの上に建てる
- spark driverがNodeManagerの上で動く
- ジョブをもらってから、コンテナをいくつ建てるかなどをNodeManagerが判断
- yarn-client mode
- spark driverがクライアント側で立つ
spark-shellをクライアントで動かすため- shellがResourceManagerとやりとりする
- yarn-cluster mode
- 問題
- yarn-clusterではexecuterの数を起動時に指定している
- RDDが消えちゃうのでexecuterはジョブが終わるまで終了できない
- stage1で100%まで張り付くと、stage2が暇になっても開放できない
- Dynamic resource Allocation
- インストールしようとすると面倒
- yarn-clusterではexecuterの数を起動時に指定している
- Sparkの上でYARNが動くので皆さん使いましょう!!
2014年やってたこと、正月休みにやろうとしていたこと、2015年やること
TL;DR
自力で推進力・実行力をモチベートする術を持ち合わせていなかった、見つけなければならない
あけました。おめでとうございました。
前のエントリは'14の5月、久々に書くたびにこれまでの記事を消したくなる衝動に駆られます。
12/27〜1/4までの間、正月休みということで実家に帰省しています。
年末年始のエントリを読んでいて、ふと何か書かねばならぬのでは、と思い立ちおもむろにダッシュボードを立ち上げました。
このブログのタイトルの割に全く仕組みを組み立てられておらず依然として筆不精なので、プレッシャーを感じているうちに書ける範囲で書き下すことにします。
だいたいWebエンジニア１年生の技術の話です。
2014年やってたこと
- 学生マークアッパーは新卒でフロントエンジニアになったかと思ったらインフラに配属されていた
- 研修の途中からバックエンドと決済処理のGUI作成をやって、それ以降ありがたいことにかなり好き放題やらせてもらっていた
- ChefとAnsibleをひとりでに書いて、インフラTDDをやるところまで
- 技術的負債をインフラ側からわざわざ延命させるようなノウハウを書いていた
- ChefとAnsibleをひとりでに書いて、インフラTDDをやるところまで
- Jenkins、Cobbler、Rundeck、SoftEther、EFK(Es, td, Kibana)あたりを建てるだけ建てて泳がせた
- 勝手にVPN環境こしらえてたら障害対応要員に加わっていた
- オレオレクラスタサーバへのデプロイのために並列分散シェル芸を仕込んだりした
- あとはVyOSやGolang、分散ストレージなどを斜め読み、教養というレベルで血肉となった実感は得られていない
- Selenium WebDriverをGUIのまま運用させる(Selenium Builder + se-interpreter)方法を検証しながら年を越した
- docker-seleniumで半ば無理やりwercker上でテストさせてる
できてないところ
- 勉強会には月２，３くらいのペースで出席していたけど、懇親会まで残る勇気や集中力はなくこのままでは横のつながりは出来そうもない
- ネットワーク界が未だに怖い
- 課題解決のための技術より技術のための技術に目線が行きがち、その割に自力ではモチベートできず、承認を期待しながらでしか働けていない
- ごくごく基本的な社会人スキルがダメダメ
- ことごとく本の読めない人生だった
正月休みにやろうとしていたこと
VirtualDOM(react.js / Elm)
generator-react-gulp-browserifyにreact-jadeを詰め込もうとして動かず、全然何もできていない
- Elm Advent Calendarの１日目を読んでテンションが激烈に高まったが、結局まともに手を動かしておらず全然何もできていない
- reactよりElmの内部でも動いているvirtual-domの方が早いので、移行難度などを完全無視してパフォーマンスだけで見るとElmの方が有能そうに見える
- ElmからFRP方面のScalaに片足突っ込んだりできたらいいな、というスケベ心はある
- Haskell単体への興味はあまり沸かなかったので、そもそも挫折濃厚っぽい
Android with Scala
- 夏くらいから夢想だけしていて、Android Studioにsbtプロジェクトを食べさせるとGradle変換しようとするので調べていたら↓の記事を拾い、Javaをふっ飛ばしてScalaで触り始めるのはだいぶ厳しいのではないか、という印象だけ受けて全然何もできていない
- mixi-inc/AndroidTraining は昨４月頃から把握だけしているものの、結局全然何もできていない
- 第1回 Android Training - connpass にうまく滑り込めたらいいなあ
Test-kitchen
- Ansible + Docker + Test-kitchen on werckerな環境を整えた
- 以前触った時はCentOS7イメージへのAnsibleを
kitchen-ansibleでカバーしておらず、途中で投げ出していた - CentOS7があまり盛り上がらないのを見て、CentOS6環境に限定してひとまずwerckerで回るところまで
- 多分el7も
provision_command次第でなんとでもなるハズ
- 多分el7も
- 以前触った時はCentOS7イメージへのAnsibleを
kitchen-docker_cliがよりスマートそうなのだけど、Chefとの組み合わせでも/tmp/kitchenディレクトリのお化けを見ているようでまだ動作確認できていない- ちゃんとコントリビュートしたい...
2015年やること
技術面
- クラウドを触る
- インフラというからには設計のレイヤーをやり始めたい
- CloudFormationないしはTerraformあたりでもう少しカジュアルに作っては壊しできるようにしたい
- DockerオーケストレーションのProduction Readyを待つ
- k8sないしはECSがリリースされれば
- ScalaとGo、という目の付け所は間違ってない気がするので、実行をどうするか
それ以外
- 承認待ちでない推進力を見出す
- 業務の範囲では下っ端ということもありうまくいっているように見えるものの、それ以外はまるで破綻している
- コレさえ解決できたら自走できる気がする...
- ビジネス(課題)からのアプローチ
- 隣の島はみるみるうちに「企画開発」の道を突き進んでいて、焦りしかない
- インフラがビジネスを語るとき、費用や保守性以外に何が言われるのだろうか
- 「甘えてはいけない、侵犯横断していかないと」、となるべきなのだろうなあ
大変遅ればせながら
先年は大変お世話になりました。
今年もよろしくお願い致します。
140523最新インフラエンジニア技術勉強会
ドリコムのInfrastructure as Code
chef soloで収束している
他社でもChef-serverで有効な事例をあまり知らない
３つの *** Driven Infrastracture
- Issue Driven
- Pullreq Driven
- マサカリDriven
- コミットに容赦無いコメントを投げ込んでいく
- 意識の高いモヒカンが四方八方からツッコミを加える
- （気になっただけです）という圧力
テスト駆動インフラ
- serverspecで作業項目を記載
- GitLabでコードレビュー
- 開発環境で実行・テスト
本番環境で実行・テスト 基本はRunDeck
serverspecはあまり強くないので早く：Chef、CIツール、serverspec
- 正確に：PDCA
P: Chef,serverspecコードレビュー
D: Chef,Rundeck実行
C: sererspec実行
A: コード修正
Rundeck
リモートサーバのオペレーション管理が便利すぎるのに無名
すでにImmutable Infrastructureを実現して必要がないのかも？
Q&A
chefからこぼれる緊急修正はどういうフロー？
- if文で限定的にやるのはどんどん苦しくなる、条件分岐に失敗するときもよくあった、特にchef-serverはきつい
- Rundeckでshを動かせるので、それが通るようにテストを修正する
- chef+sh(<-Rundeck)
ラピックがすべての作業を履歴・実行者管理している
- サーバーコピー、chef、Rundeckの３つで適材適所な感じ
ドリコムにおけるWinning the metrics battle
Graphiteと戯れたり、インフラ改善施策とか
サーバー状態の収集と閲覧を簡単にできるようになるのは重要、しかし1300台を超えると工夫が必要
工夫をしなかったがための失敗について
このままだと破綻する！->
- サーバ（モニタ対象）が自動で追加される
- グラフが自動でレンダリングされる
- 情報を中央に集めるのに必要な機能
- スケールアウトができる
Munin, Gangria: 先輩「グラフが好みじゃない」で却下
- 普段使いなので習熟度が低いものが欲しい、しかしいいものがなかった
→作った
↓
Mine
地雷を探すシステム
Ruby + Padrino + Backbone.js
Graphite : グラフ描画、メトリクス保存、URL API、プッシュ型
URL API
target=averageSeries(hoge-web-*.nginx.response=) ←関数
平均、移動平均、などなど、形式もSVG、PNG、json、CSVで返せる
プッシュ型
プル型→収集したいサーバーに取りに行く、手動で登録する（並列で取る）のは数百台で限界
プッシュ型→監視サーバーにそれぞれが送りつける 多少失われても困らないのでUDPで投げる
管理用サーバーをchefで構築するだけでノードが増やせる！
Collectd
Graphiteへ情報をプッシュするミドルウェア
軽くて、機能的に十分
Cactiとの違い
APIがない、グループできない、RRDなので画像しかない、プル型
今後
複数サーバーをサマライズしたり 100台の平均レスポンスを出す→見るグラフを最小化する 異常値がわかりやすいように →最大値・平均値・最小値をプロット →頑張りすぎ、サボりすぎを見やすくする
アーキテクチャ
複数データセンターのサーバー→各Collectd→暗号化して中央のCollectd→復号化→carbon(Graphite)→Mine
collectdは冗長化済み
carbonは暗号を受信したらハッシュで分割、データセットへ
データを書き込み→DRBDで同期、grapdite-webを叩いて見れる状態に 中央のcollectd→grapdite-webまでも冗長化済み
表示
UserがMineを見て、g-webにリクエスト、複数サーバーから探索
まとめ
1300台を5分間隔で取得 プッシュ型、手動では限界がある、Graphiteに蓄積するのはよさげ
Q&A
- 5分間隔で１年分は保存されている
- 100台だとほとんどかからない
Fruentd プラグイン開発
外山寛さん 株イプロス
運用ツールとして認識されつつあるFruentd プラグインを自分で作れれば威力が倍増します
elasticsearch勉強会もやってます
DevOps向けFluentd勉強会も
公開されているプア溜飲だけではやはり実現できないことが多い ビジネスロジックに依存した大規模なものも、プラグインなら
使っているプラグイン
- redshift
- elasticsearch
- mysql-replicator
- leftronic などなど
作ったもの
- mysql-bulk
- split
- ...
未公開
- sedue
- qiita
- backlog
作る理由
- ない
- 微妙に使い方が違う、パラメータで吸収されない
- 簡単に作れる、rubyでかける
用語解説
chunk
種類
- buffer output
- output
- input
- time slice output
- multi output
buffer output
- チャンクのキューを維持する
- インターバルの指定
- 真の意味でのリアルタイムではない
- 送信失敗時の再送機能
- 代表作
- elasticsearch
- growthforecast
使うとき
外部要因に依存する場合 失敗が許されない通信 逐次じゃなく、一括でやりたいとき
- elasticsearch
- 落ちていたら？
- td
- treasuredataで障害があったら？
- redshift
- awsで障害があったら？
→再送してくれる
output
- 即時送信
- 失敗時の再送機能はない
- 真のリアルタイム、に近い
自分自身が処理のディテールを持っている時 信頼性を特に重要視しない データを加工して次のプラグインに渡すときとか
- 代表作
- rewrite-tag-filter
- parser
input
- 外部からの入力を定義
- WEBAPIなどを入力にするとき、streamingっぽくするときには自力で実装する必要がある、APIの実装に依存
- あくまでポーリング、イベントドリブンではない
使い道
- WEBAPIのポーリング
DB、外部サービスのポーリング
代表作
開発プロセス
ここからは想像だけで作ったベストプラクティスです
- ローカルfluentdで開発
- git push
- td-agentで動作確認
- gem push
fluentd -p xxxxxxで読み込んで開発
-cで設定ファイルを指定
- 以下のメソッドを定義
initializeLibraryの読み込み
configure
emit, wiret, run実処理、ここがキモ
コールバックの処理をどんどん書いていく
buffer_outputのときはchunk(配列)で飛んでくる
パラメータの定義
データ型：string, bool, time, integer
V1ではhashとarray、環境変数も使える模様
ここまでやって大体githubにpush
、gem push大変、そもそも社内でつかうから公開したくない →プラグインフォルダに.rbをコピーして再起動
.rb１つで作れます
必ずしもgemにする必要はありません、無理なくはじめましょう
td-agentテスト
fluentdを直接使ってる人は少ない印象
逆にfluentd使ってtd-agent使ってない人いる？→会場ではゼロ
rubyやfluentdのバージョンがズレる時がある
逆にtd-agentに合わせてやる
travis-ciなどでバージョン横断ユニットテストを実行
リアルな話、プラグイン作り始めたら無茶ぶりにも耐えられるようになってきました
あんまり効率的じゃない結末、がなくなってきた
Q&A
- エラー処理は？
フォーマットのエラー処理はスルー、V1ではエラーを流せるっぽい - 単体テストのやり方は？
人によってバラバラみたい
MySQLと組み合わせて始める全文検索エンジン"elasticsearch"
リブセンス よしけんさん @yoshi_ken
elasticsearch歴１年未満
こんな悩みありません？
最近('14 2月)1.0が出ました、アツいです
そろそろSolrを追い抜かしそうな勢い
弊社でも検証が始まった段階です
MySQLとのデータ連携
Solrよりモダンである一方、互換性は作りこみの余地ありなので
今回のテーマ
異種RDB間の同期
作りました
↓
Yamabiko
y-ken/yamabiko
CentOS6向けrpm配布中
削除検知ができる PKeyキャプ判定で実現、数上万行でも動くけどちょっと重たいです
- BinaryLogではなくSQL結果で同期する理由
- JOINなしでやるNoSQL概念に対応させるため
- 非正規化VIEWテーブルを作ることを想定している
新たな課題
差分検知が遅い問題 各行のハッシュ比較が重い
→作りました
↓
elasticsearch_mysql_importer
MySQLデータ→elasticsearch の手間を最小化するツール
Yamabiko同様、ドキュメントのネスト化が可能
y-ken/elasticsearch_mysql_importer ただいま公開
(ライブrake release)
利用例
- 実装なしにMySQLレコードを流し込んで検索へ
- １レコードに複数紐づく属性情報をネスト構造で検索したい
- 非リアルタイム更新なWebサービスでの利用
- 求人、賃貸、グルメ、商品情報、口コミ
- 都度インデックスを作り直す、１００万行程度想定
Groove Incrementっぽい構成
利用サーバをデプロイごとに切り替える、blue-green deployment手法
git clone... cd elastic... bundle install --path ven... vim example.rb curl -s _XPOST localhost:9200/_bulk --data-binary@request.json
ユニークキーを指定、出力先パス指定、
ネスト構造化の仕組み
- skills
- member-skill
- members のパターン
jsonの"skills": 以下にネスト構造で
プリペアドクエリ設定を使って、tmpテーブルを作っている
SELECT skill_name, skill_url FROM tmp_member_skill WHERE member_id = ${member_id} AS skills
あまり複雑なことをせずにネスト構造を実現しました
まとめ
- elasticsearchが本格的に使えるプロダクトへ成長した
- elasticsearch_mysql_importerで手軽に始められる
- elasticsearchの国内トレーニングや日本語書籍もあります
core elasticsearch on jul 14 in tokyo @赤坂
「Elasticsearch on Server」
git merge --no-ffは悪者ではなかった
前に書いたmerge.ffがマージメッセージとは全く関係なかったことに
つい最近になって気づきました。
ホントの解決策はコレ。
echo 'export GIT_MERGE_AUTOEDIT=no' >> ~/.oh-my-zsh/custom/git.zsh
>>以降はよしなに。自分はoh-my-zsh使いなのでcustom以下にモジュールとして書きました。.zshrcが走査すれば。
この間までは全然気にならなかったのですが、git 1.7.10以上ではマージメッセージはデフォルトではinteractiveになっていたそうで、思ったより前からあった変更でした。
git merge --no-ffをデフォルトにしたらめんどくさい目にあった
(追伸：2014-05-06 git merge --no-ffは悪者ではなかった - したためなければいきのこれない)
git config --global merge.ff false
でnon-forwardマージをデフォルトにしていたのですが、
brew updateとかupgrade_oh_my_zshとか
アップデートのたびにエディタが立ち上がって大変に面倒くさくなった。
新しくブランチ切るから毎回コメントしたためないといけなくなるんですね。
git-flow運用は--no-ffの方が各ブランチの軸が動かなくて見通しが良いらしいのだけど
この一件を踏まえてリポジトリごとにちゃんと忘れず設定するようにします。
