鱒身(Masu_mi)のブログ

知った事をメモする場所。

RTPを少し調べた

GoRTPのサンプルコードを使って中身に目を通しつつ仕様を勉強していた。

とある会社に興味を持ったためにRTPに興味がでた直接のきっかけ。 もともと負荷分散とか低レイテンシ化を目指した脱TCPに興味があったので少し追ってみた。

Read more...

Supervisordの練習(Airflow)

daemontoolsは設定が色々あり辛いのでSupervisord を覚えることにした。 練習としてAirflowをデーモン化した。

簡単に説明するとSupervisordUNIX likeなシステム上で複数のプロセスの起動を管理を提供するserver/clientシステムで 起動停止の他にイベント検知などもサポートしている

Read more...

OAuth 2.0による認証を試してみた

OAuth 2.0で認証してみた。

まずOAuth 2.0は認可フレームワークで認証は直接サポートされない。 だけどユーザー属性参照への認可(アクセストークン)で似たことができる。

実装が簡単なためOAuth 2.0で定義されているAuthorization Code Grantを利用して認証をする人が増えた。 これは野良ハックであって認証として合意は取られていない。 なので認証としての機能拡充や仕様として整理するためにOAuth 2.0上の認証機構OpenID Connect 1.0が定められた(と思われる)。

OpenID Connect 1.0のクライアントは利用するだけなら簡単との事だけど仕様を理解するのにだいぶ時間が掛かりそうだったのでOAuth 2.0のハック版の認証を試してみた。 Authorization Code GrantにはセキュリティリスクがありRFC7636で対策が策定されている。 だけどgithubのドキュメントで対応を見つけられず今回は実装していない。

Read more...

Gottyを使ってみた

ttyをブラウザ経由で利用できるツールはいくつか存在する。 Go実装のyudai/gottyを試してみた。 とてもシンプルで簡易で何かするのに使うくらいだと思われる。

あとからfork版のyubo/gottyを見つけた。 こっちは機能が豊富でパッケージ化も進んでいて扱いやすそう。

Read more...

Golang:testing Example

GoにExample functionテストがあるの知らなかった。

とりあえずExampleXXXX()って関数名で使える。 キーワードはOutput:, Unordered output:って2つのコメントになる。

ドキュメントによるとExampleテストの関数名で対応する関数やメソッドを解決してGodocのExampleに掲載してくれるらしい。

Read more...

Update to Go 1.8

先日Go1.8 がリリースされた。 ソースコードからビルドしたら失敗した。 調べてたらIssueが上がっていて対処が判明したのでメモしておく。 ついでなのでリリースノートについても目を通した。

Read more...

Golang: contextを使ってみる

contextについて調べたので試しにos.Signal を受け取るとキャンセルを実行するcontext.WithCancelBySignal()を作った。

書いてから振り返るとcontextはトランザクション単位で用いるがos.Signalはプロセス全体に関わるため概念が一致しづらい。 exec.CommandContext()SIGKILLを飛ばしてしまうので子プロセスは直ちに死ぬ。そのままでは使えず相性が悪い。 ただ作ったのでとりあえず残す。

Read more...

Golang: contextを試す

勉強したことのメモ。

contextはv1.7から標準パッケージに含まれている。 関連処理をgoroutinによって非同期に実行する事が多いGo言語では対象トランザクションに関連した処理に対して横断的な制御をするのに苦労する。 contextパッケージがインタフェースを整えてくれる。

現在は主に2つの機能を提供している。

  • トランザクションの属性情報を共有
  • タスク間の依存関係をツリーを管理(キャンセル(完了)を下流に伝搬させる)

主に、キャンセル通知の伝搬経路としてcontextを捉えると考えやすい。 キャンセル対象は何でキャンセルされず実行するのは何かを分類するとcontextの親子関係のデザインが固まると思う。

またトランザクションは複数プロセス・ホストに関わることもある。 os/execCommandContext()net/httpRequest.WithContext()などがプロセスに閉じこもらないトランザクションの挙動やキャンセル処理に貢献している。 当然だけどプロセスが異なる場合はキャンセル処理を親側が実施する事で伝達されるがcontextのインタフェースとして伝達されるわけではない。

属性情報の共有の方針は賛否両論な2通り出てくると思っている。

  • トランザクション単位の情報(request_idなど)を横断的に共有する場合にcontextに含めて持ち回る
  • http.Requestをラップしたリクエスト構造体やインプット構造体を引数としてドメインレイヤーに渡す

一般的にはinteface{}を嫌うのでデータを入れることは避けられると思われる。 なので気軽にアプリケーションに閉じ込める場合はcontextを利用するよりリクエスト構造体を利用する方が好まれると考えている。

ログ用の情報などアプリケーションと関連しない一般的な横断情報とは何かの合意が取れたり慣例が貯まれば、 ミドルウェアやフレームワークがhttp.Requestをラップせず標準ライブラリと同レベルの抽象化を維持できるためcontextに寄せた実装も少しずつ出てくると想像している。 その場合contextをフレームワークやライブラリが利用する構造体にラップすることでユーザーはinteface{}を直接触らない様に提供されるのが原則になると想像している。

どちらの方針を取るにしても、バックエンドへのクライアントなどサービス機能についてcontextとは役割が違うので入れるべきではない。

Read more...

アルゴリズム練習: Chord

分散システムを自分で設計・実装できるようになりたいので基本的な分散アルゴリズムを勉強したり実際に書いてみることにした。 教科書に従って書いていて、用語などの前提には触れずメモを残すだけなので読むの辛いと思う。

tl;dr

DHT(Distributed Hash Table)を実現する代表的なアルゴリズムであるChordを実装してみた。

DHTっていうのは構造化オーバーレイネットワークの1つで多数の分散したノード上にハッシュテーブル(set, get)を提供するシステムを指す。 Chordはそのようなサービスを提供するアルゴリズムの1つで、ノードのアドレスとデータのキーを同一のS1集合へ射影することで資源探索を行う。 またノード数Nに対してリソース提供ノードを確定するのに必要なノード数をO(logN)にするように経路表を維持している。

../../../_images/new_ring_completed.png

多数のノードがつながりリングが形成されている (ピンク: succ, 青: pred, 点線: fingers)

とりあえず実装したのはRendezvous, Location, Routingのロジック部分で実際の通信やKVSサービスは実装してない。 簡単なコードのテストは書いたが複雑な部分はシナリオを通過したノードがどのようにつながっているかdot形式で出力して可視化した。 論文の他に教科書(Distributed Computing)も参考にした。詳しい解説スライドも読みました。

Read more...

内製技術を公開するにあたって

主にソフトウェアについて社内の既存のソフトウェアに対する競合技術が社外に現れたと感じた時の判断する目安について妄想してみた。 関連して新たに社内で開発する前に検討する事も考えてみた。

ミドルウェア・プラットフォームを内製するか迷ってる

既に社外に類似サービス・ソフトウェアがあるか調査して存在しなければ内製すればいい。 要望・要件と目的を整理して検索して出てきたシステム・サービスを列挙する。 満たせている/満たせていない、をカタログ的に分類する。目的や要望・要件に変更を加えられないか検討する。 変更を加えた時のデメリットを検討する(一般化できずに社内で使いまわせないなど)。

要件や要望が類似している場合には内製根拠が必要になる。 利用に際してライセンス料・サービス利用料が大きい、検証によって要件を満たせない事を示すの2択が考えられる。 検証によって要件・要望を満たせない事が示されたら、更に提案や要望による貢献で解決できないかも確認する。 長期的にみて改善しそうでも期日に間に合わない場合で、更に内製で間に合うと判断できる場合はそれを採用する。

  • 最適化の方向が異なり改善提案は成立しない
  • アーキテクチャ的な問題により長期的に改善が見込めない
  • 要望をコントロールできない。

内製してみる

社外エコシステムを取り込みやすい様に開発する。

既に独自開発していて競合(ソフトウェア・サービス)が力を付けてきた

気づいたら早めに課題を指摘して社内技術を公開して共存できる様にする。 これがコミュニティを育てて社内技術のレガシー化を防ぎつつ開発リソースをアウトソースするのに繋がる。

公開する内容の選択肢

4つの選択肢をを考えてみた。2つ目以降は(少なくとも間接的に)インタフェース公開が含まれる。 インタフェースについてはエコシステムに貢献して強い立場を作ったり、社内技術がガラパゴス化しない様にできるかを左右するので慎重に扱いやすく外部との相性も良くなるように整理しておく必要がある。

  • 課題 + 方法(特許, 論文, 白書, 記事)
  • 課題 + 方法 + インタフェース
  • 課題 + サービス (+ インタフェース)
  • 課題 + ソフトウェア (+ インタフェース)

公開する前に、内製ソフト・プラットフォームで満たしていて社外で満たせていない要件や要望や課題について整理する。

下手なものを公開できないけど早めに貢献したい

関連する内製ソフトウェアの要望・要件から外部と共通の一般化できるばしょを確認する。 外部では満たせない項目は何に依存しているのか調査する。 一般化ができたり自然に辿り着く様な事であれば上述の4つの選択肢などを実践して貢献するのが良さそう。

どの選択肢でも、技術力や主導権を維持してエコシステムが滅びないようにコミュニケーションを測るのが大事になる。 特にソフトウェア公開ではコミュニティの運用や宣伝が必要になったりとマネジメントコストが増す可能性がある。 コアコミッタやってた経験がある人がいたら聴いてみたい、案外そんなことないのかも。

社内要件というかアプリケーション要件がべったりな場合は要件整理のチャンスと考える。 整理の後で一般化されうる部分は、外部に貢献する社外システムを取り込みメンテナンスコストを押さえるか再び検討する。

社内開発をしつつ社外に対して孤立しないための技術マネジメントってこんな感じなんだろうなって思ってる。