OpenCensus meetup vol.1 に参加してきました！！ #opencensusjp
参加してきました
https://opencensus.connpass.com/event/123885/
いやー面白かった。
自分が気になって見積もりに時間かけてるところがやっぱりネックになっていて、みんな気にしてるという同じ認識を持てたのもよかったです。
京都からきてよかった。
資料リンクだけ並べてるので、感想は後ほど。 -> 書いた!
なぜに京都から???
rohki.hatenablog.com
前に調べたり、Scala 関西で @grimrose さんの話きいたりしてました。僕にとって今一番面白いところだからです。
面白さの背景を書くと、Managed Service を使っていてメトリクスやログがとりやすくても追跡はひたすらしんどいってのを何度か味わってるからです。
ロードバランサーのエラーコードの発生個所や遅延の発生、HTTP のアクセスログ、アプリケーションログ、サーバーのリソース消化具合、DB のクエリの遅延やトランザクションの待ち、キャッシュのヒット率、Disk IO、Disk Queue、などなどなど。
AWS の Managed を使ってるとこの辺りは取れます。取れますが、これらを組み合わせてサービスを構築しているのは自分たちで、各メトリクス・ログの因果関係を追っていく必要があります。
僕は CloudWatch/Elaticsearch を使って追ってます。追っていますが、ひっっっっっっじょうに疲れるんです。
インフラ構成を脳裏に置きながら、みんなで仮説を立てて、関連するメトリクスを洗い出し、同じグラフに描画して、まず相関があるかを確認する。
これ繰り返すだけでお腹が一杯になってしまって、原因らしきものを特定したときにはすでにグロッキーなのです。
この特定までの負荷を安くして、一次対応とか根本対応どうするにもっと時間をかけたい、ってのがきっかけです。
本編
イベント主旨説明 / Opening / @ymotongpoo
資料 URL: https://bit.ly/20190403-oc-intro-update
アンケート見ながら、やっぱり StackDriver つよいなーという。場の問題? それはあり得るw
書きながら改めてみると Zipkin や Jaeger が少ないのも面白いです。やはりこの辺りを自前でやるのはつらいというこうとでしょうか。
運用の運用で奔走させられそうな雰囲気を感じます。
Session 1: OpenCensus Intro and Status Update / @ymotongpoo
資料 URL: https://bit.ly/20190403-oc-intro-update
会場の雰囲気としては、Service への期待が大きかった気がしてます。というか僕が期待してます。
Reverse Proxy や Service Mesh に tracing 機能もこちらによるか、ないしは連携できると色々はかどるのかなぁと思ったりしてます。
OpenTracing とのマージの話は後にも出てきますが、うん。ちょっとごまかそう。うん。
Session 2: OpenCensusを実際に使ってみて、便利なところと、困ってるところ / @sinmetal
資料 URL: https://docs.google.com/presentation/d/1J0fh9_C-Juhy1N3EB1G9PqR8NRWgwJjb0VCy7VfRbXI/
趣味のゲーム https://github.com/metal-tile
まさしく聞きたかったお話でした。Sampilng rate と追跡性のお話。
低すぎると取りこぼしがでて、高いと負荷とお値段があれで、じゃあ一時的に全取得ってやってみたら Buffer full で捨てられて…
特に最後かなぁ。全取得が難しいケースもあると分かったのはとても大きいです。この辺りは実装と設定によりそう。
Session 3: Distributed Tracing with OpenCensus at Wantedly / @munisystem
資料 URL: https://speakerdeck.com/munisystem/distributed-tracing-with-opencensus-at-wantedly-inc
Wantedly さんで投入されたお話。
これも聞きたかった話ですねー、Sampling rate とか性能問題とかAWS X-ray と比べてのところとか。
X-ray の導入で悩ましいのが、AWS 色が強すぎるところなんですよね。
OpenCensus の Partners & Contributors でも Google と Microsoft は入っていて AWS は入ってないというところがあります。
Library の話は強い！！という感想。場合によってはそういうこともありますよね。うーむ。
あと、バックエンドへの最適化が話に上がっていて、抽象度あげたいから OpenCensus を入れたけど痒いところに手が届かないという、バランスの難しさもわかりました。
ここでも OpenCensus Service の話題。期待たかいっすよね。
Session 4: OpenCensus Javaで始めるOpenCensus / @grimrose
資料 URL: https://docs.google.com/presentation/d/1i3LYjz26lz8WWuIqcwBpc8d0I-8_kTu7hnDWvdnOZEE/edit#slide=id.p
Java 実装 Android で動くんかい！！ 元クライアントエンジニアとして確かに知りたいときはある。あるものの、どうやって送るんだそれ???
通信負荷考えると Sampling rate もっと考えなきゃ云々。
閑話休題
Java は Exporter のサポートが厚めですよね。対応状況も Beta ですし。
Spring Cloud は知らなかった…調べてみよう。
ちょいちょい Scala 実装の話があって個人的に非常にありがたいw
try with resource の話がちょっと盛り上がっていたかも? golang の defer の話が上がっていたからかもです。
LT1: JavaのCustom Exporterを書いてみた / Writing custom exporter for Java / @r_rudi
資料 URL: https://docs.google.com/presentation/d/e/2PACX-1vRMNdvFdqwHlyfgj8fAQA-sU391UooWegR2s87rpUD9RzOsPzxnycoH3LkZDt12v48kxmphq68qa-Y_/pub?start=false&loop=false&delayms=3000&slide=id.p
https://github.com/shirou/opencensus-exporter-trace-xray
Session 4 と関連が強い、ということで順番をいれかえて LT トップバッターへ。
そうそうこれこれ。X-ray との話。というか強い。
スライド 11 にある対応表とかめっちゃありがたいです。なるほどなぁ。
LT2: TracingとLoggingの連携 / Tracing and logging correlation / @ladicle
資料 URL: https://speakerdeck.com/ladicle/integration-with-tracing-and-logging
https://github.com/Ladicle/opencensus-and-jaeger
gopher くんの好みの話でざわっとなって途中から気になるところが変わってしまいましたw
そうか、ニンジンがすきで魚が嫌いなのか… デモもそれにそってやられてて思わず笑ってしまいました
それはさておき。
Tracing と Metrics と Logging の関係図よいすよね。この図を念頭に置いて設計してきたい
OpenTracing との話は、うん。
LT3: OpenCensus Stats で PaaS のメトリクスを補完する / Interpolate PaaS metrics with OpenCensus Stats / @apstdnb
資料 URL: https://docs.google.com/presentation/d/17E5TqNuq46_8B62beMOg_1bHY_jDVBTdmzSJYrqKLgs/edit
自己紹介が強すぎるw
当然ながら GCP は本家本元に近いので連携が強いですよね。資料も豊富だ。
悩ましい…
LT4 : Ruby実装についてひと言 / Ruby implementation / @kawasy
資料 URL: https://speakerdeck.com/kawasy/current-status-of-opencensus-ruby-number-opencensusjp
良かった。なぜかいまいちな Ruby 対応に関してひとことでした。お、Feature MatrixにRuby足されとるやん https://t.co/niNphzvgxe #opencensusjp
— progrhyme@技術書典6「か59」 (@progrhyme) 2019年4月4日
というより Erlang/Elixir の強さが何でそんなに強いのという。Beta にはいってますやん。
やっていく宣言はかっこいい！！
LT5 : ウェブフロントエンドからサーバーまでの一気通貫のトレーシングに挑戦してみる / Try consistent tracing from web frontend to backend servers / @shibukawa
資料 URL: https://docs.google.com/presentation/d/145vr-ouZFxlLub5dGyl3TkJmxqWqPMvmuZObUMgRzEg/edit
https://github.com/shibukawa/opencensus-sample
これもこれで面白いですやつ。僕個人の話でいうと、フロントエンド周りの知識がよわいんですよね。
確かにここきっかけでリクエストとか描画のタイミングが追えるようになるかも? 性能問題が出ないように気を付けながらですが。
Observablility は港区用語。港区用語とは…(関西在住 エンジニアの感想)
Real っては確かによい表現。その時の Real が知りたいのです。
おわりに
雰囲気よかったです。
なんとなくみんなの興味の根っこが同じでありつつ、いろんなアプローチがされていました。
vol. 2 も参加できるかな?
nand2tetris に入門中
コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方
- 作者: Noam Nisan,Shimon Schocken,斎藤康毅
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/03/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
01 の nand gate のところをやってます。 ベン図とかド・モルガンの法則とかの懐かしワードをどうにか思い出して解いてます。
なんか基礎をのばしてーなーと思って会社の制度を利用して今手元にあります。ありがたい。
書籍の公式サイトがあって、↑にシミュレータのプログラムもあります。
テストスクリプトもついてるので、サクサクと試行錯誤できてよい感じ。こーいうのやってると大学時代思い出しますねー
(追記あり) AWS Lambda が正式に Rust 対応したので KinesisFirehose にくっつけて性能計測した #rustlang #rust_jp
これは Rustその2 Advent Calendar 2018 の 2 日目の記事ということにしました。
結果(2018/12/3 更新)
ありがたい PR のおかげで更新できました！ tatsuya6502 さんありがとうございます！
246k record を 57.6 秒で処理したので、4,270 record/sec でなんと 4,000 の大台突破です。
修正内容は僕がサボったところを指摘いただいた感じでした。むしろすみません。
| Runtime | record/s |
|---|---|
| Python | 142.8 |
| Rust(on Python 2.7) | 2348.6 |
| Golang | 3910.0 |
| Rust(on Custom Runtime) v1 | 3967.2 |
| Rust(on Custom Runtime) v2 | 4270.0 |
ということで、4,000 を越えました！すごい！！
成果物
これまでのあらすじ
rohki.hatenablog.com rohki.hatenablog.com
初めて Kinesis Firehose で計測してから 1 年弱、 Golang で計測してから 10 ヶ月弱…
ついに正式対応ですよ！ なんかもっとすごかったけど！！ ということで、ここまできたら計測せねばということでやりました。
実装
去年に作ったやつを適当にちょちょっと書き換えたら動きました。時間は 2 時間ぐらい?
この辺は数をこなしたおかげかと思っとります。
ほぼ一緒とも言う
— rohki (@r_ohki) 2018年12月2日
せっかく linux 環境作ったし、そのまま build したやつ動くかなーとやってみた結果、llibc のバージョンで怒られました…。
そして glibc すか…
— rohki (@r_ohki) 2018年12月2日
静的リンクすればいいんんだろう、ということで musl 版を以下を使って作りました。 rohki.hatenablog.com
コマンドは以下です。
cross build --target x86_64-unknown-linux-musl --release
計測環境
- Runtime: Custom Runtime
- メモリ: 128 MB
いつも通りの下限性能です。
これまでと同じどおり、Kinesis Data Generator で Apache Log っぽいものを投入して、時間あたりでどれだけ処理できるかをみます。
結果(再掲)(2018/12/3 更新)
246k record を 57.6 秒で処理しました。
| Runtime | record/s |
|---|---|
| Python | 142.8 |
| Rust(on Python 2.7) | 2348.6 |
| Golang | 3910.0 |
| Rust(on Custom Runtime) v1 | 3967.2 |
| Rust(on Custom Runtime) v2 | 4270.0 |
と、いっても最大風速の性能がならんだ、というところです。
感覚的には 3800 から 3700 が平均性能といったところでしょうか。それでも十分速いです。
今回は速度も安定してました。毎回 4,200 record/s を安定して出していたので、予測しやすくなってます。
んで、実戦投入できる?
熱意と覚悟、Lambda のコスト削減に並々ならぬ事情があれば。
Lambda の仕様を考慮した build まわりのややこしさがどうしたって足を引っ張ります。
OpenSSL の反省を踏まえて今回の GLIBC はさくっと対応できましたが、Lambda の仕様と対応策の検討が追いつかないとひたすらハマる落とし穴でした。
動いてますがなんか見落としがありそう…やるのであれば場所を選んで少しずつって所かと思います。
さいご
ついに正式対応。感慨深い…
書いてさらしたら PR もらえた。ありがたい…
PC 新調した
ひさしぶりの Linux 環境である。
Wi-Fi につまったり、日本語入力の設定につまったりしたけども、まぁ動きました。この記事も新しい端末から書いてます。
やったこと
- Wi-Fi ドライバが認識されなかったので、ドライバを追加してビルドした
- Secure Boot が邪魔していたので無効化した。
- 日本語入力を設定した。iBus とか懐かしい
- mac から zshrc を持ってきた。パスを修正すればいけた。
- Password Manager にログインした。Dashlane 使ってるけど、Add-in だけでどうにか使える
ちょっと感動したこと
DuckDuckGo で Wi-Fi について調べたら、右側に手順が出ましたよ!
内容はフォーラムから引っ張ってきている模様。
ちょっとこまってること
TouchPad が大きいせいで、カーソルがとんじゃいます。変なところに文字入力してて辛い。
キーボードは固めかなー。そのうちなれるでしょう。
感想
パスワードマネージャと zshrc があればセットアップはわりと楽なもんですね。
次は開発環境構築。
Scala 関西 Summit 2018 でいろんな体験をしてきた #scala_ks
よかったー
新しい話をきいたり、初めて会う方とはなしたり、コントリビュートできたり、なじみの人に会えたり、同じ志向の人に会えたりしました。
まずスタッフの方と発表いただいた方、参加者のみなさん本当にありがとうございました。
印象的だったこと
Akkaを分散トレーシングで見てみよう by とーます さん
同志よ！(一方的)
こんな調べものをしていたのでちょーワクワクしながら待ってました。
で、聞いてる間もひたすら頷いてそだよなーという感じ。
発表の後で話した時に
- 僕「ocjdbc 試して詰まったんですよねー…公開されてなさそうだし、Gradle だから sbt の git 指定では難しくて…」
- とーますさん「あれはですね、最新は 0.0.2 なんですが 0.0.1 は公開されてるんですよ！」
- 僕「!?」
とか
- 僕「リクエスト数とサンプル数と容量の調整難しくないですか?」
- とーますさん「そうなんですよねー」
とか。
分散トレーシングで詰まっていたところが解決したり、想定していた懸念点がその通りだったりととてもありがたかったです。
「ブログみました」もうれしかったです！書いてよかった…
OSS コントリビュート
2 日目のアンカンファレンスにて id:takezoe さんとお話しながら、サクッと GitBucket へコントリビュートできました！
本当に貴重な機会でした。
https://t.co/KkfSpgWoTP
— rohki (@r_ohki) 2018年11月11日
おー、@takezoen さんとお話しながらでスッといれていただきました! #scala_ks
いいおっさんなのでビビらずやれって話なんですが、いかんせんビビりなもので。
コントリビュートできたこともそうですし、Java や Scala の OSS 事情的なお話も興味深かったです。
経験できたってことが何より大事かなーとおもっていて、これで一つハードルを越えられた気がします。がんばってこう。
Akka と k8s
アンカンファレンスにて他の方が挙げたところに便乗して質問しました。
というのも、以前 Envoy の話を聞きました。
この時に聞いたコンセプト「アプリケーション開発者がドメインに集中できるようにする」と Akka がどこか同じような感じだなーとぼんやり思っての参加でした。
解決をどうすればよいのか、までは至れてません。そのあたりは各々の製品特性によるでしょうし。
それでも意見を上げて、反応をもらえるってのは貴重な機会でした。
全体を通して
お久しぶりですといったり、スタッフをされてた学生の方と盛り上がったり、同じことを調べてる方と情報交換したり、新しいことに挑戦できたり、2日間でいろいろなことができました。
パワーワードが生まれるところにも立ち会えましたし。
来年も参加しよう
Rust で書いた HTTP サーバーを Github 経由で Zeit へデプロイした
成果物
でけたー。面白い。
Zeit
クラウドベンダーの模様。
CDN やら DNS やらがある。
今回はインスタンスを作るタイプ。
Docker でデプロイ
Docker image でデプロイできるすごいやつです。
僕にとっては、デプロイ先のサーバーがない状態になります。
CLI 上で操作ができるよう、バイナリも用意されています。
Github との統合
が、今回は Github との統合を行いました。
Pull Request を送ると、すぐにデプロイが始まる感じです。
こんな感じ。
ぶつかったこと
100 MB 制限
Docker image の上限が 100 MB まででした。
適当に書いた Dockerfile ではあったものの、400 MB…
ちょっと根本的に考えを変えないといけない感じです。
解決: Multi stage build
FROM ekidd/rust-musl-builder:stable AS rust-builder ADD . . RUN cargo build --release --target x86_64-unknown-linux-musl FROM alpine:3.8 COPY --from=rust-builder /home/rust/src/target/x86_64-unknown-linux-musl/release/zeit-sample /usr/local/bin RUN apk add --no-cache ca-certificates && update-ca-certificates ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt ENV SSL_CERT_DIR=/etc/ssl/certs CMD ["zeit-sample"]
以下 2 つを参考にしました。
こんなことできたんすねー。知らなかった…
Multi Stage Build という手法で、ドキュメント もあります。
ビルド環境と実行環境を明確に分けることで、デプロイに使用する Docker image の内容物を最小限にできます。
上記で最終的には、6.6 MB になりました。
やってみて
✅ ポートを自動検索してくれる
最初 EXPOSE 書いてたんですが、自動で見つけてくれるらしくいらなかったです。
✅ Cold 状態からの起動が早い
5 分(だったかな?) で環境が Cold 状態に移行するのですが、そこからの起動が早いです。
Cold 状態からの起動だった場合は、上記したポートの自動検索の結果がログにでます。
でも、その差がわかりづらいです。
✅ Github との連携が楽
自動でやってくれるのはよいですねー。
Dockerfile 書いて now.json 書いたらデプロイまでやってくれるってのはありがたい。
❌ 100 MB 制限がキツい?
環境や言語によっては、100 MB の制限は厳しい、のでしょうか?
Runtime やバイナリの大きさ次第では、この制限を通過するために、あれこれと努力する必要が出てくるかも。
Golang の 1 バイナリで済むというデプロイしそうがここでも聞いてくるのかなーとか思いました。
先ほどのビルド環境と実行環境を分けることで、純粋な Linux 環境にバイナリをコピーすればおしまい的な。
おわりに
で、この文章を書いてるときに関連文書を見直してるとサンプルを見つけて、かつ Rust もあるという…
now-examples/rust-rocket at master · zeit/now-examples · GitHub
おんなじじゃん！！！
ちゃんとドキュメントというかリリースノートというか、そのあたりは読みましょう…
それはさておき、デプロイの方法とか環境情報の持たせ方とか、パフォーマンスの考え方、そして実装方法。
特に初期起動コストを支払う回数が増えるってのが違うかも。
builderscon.io 2018 に行ってきた #builderscon
はじめに
いやー、最高でした！
2016年からなんだかんだ 3 年連続参加してました。
以下で特に気になったところの書きます。
IoT の闇 / id:kazuph1986 さん
やばいしか言えないくらいやばい #builderscon
— rohki (@r_ohki) 2018年9月6日
SNS 禁止なのであまりかけず上記が全てではあるのですが、ひたすら頷いたり質問したりしました。
昨年に続き、こういう話が聞けるのもいいですよねー。
しかし書きたい。共感したことをひたすら書きたい。
Envoy internals deep dive / Matt Klein さん
Envoy の名前は聞いていて、役割も知っていた つもり でしたが、もっと凄まじいものでした。
ネットワークについてのありとあらゆることをやり、アプリケーションエンジニアを業務ロジックに集中できるようにする、という強い意志を感じました。
一方で、当然ながら Envoy がそのあたりのつらさを一手に引き受けることになります。
(こーれめっちゃ複雑じゃん)という感想を発表中に持っていたら、「(Envoy は)複雑なプロセスである」「利用する時はネットワークを知った上で」という発表があり、やっぱりそうだよねーと安心しました。
ネットワーク詳しくならなければ。
Understanding Microservices with Distributed Tracing / lita さん
過去にこんな調べ物をしていたりしてたので、こちらに。*1
アプリケーションを開発する方が追跡性の注入を意識しなくていいようにする、を徹底されててすごいなって感じでした。
Envoy の話を先に聞けていたが故に、内容がするっと入ってきました。良い構成したよ！
こちらでは質問しました。内容は「分散トレーシングで DB アクセスをつなげて出すためには、Envoy 経由になる? それとも DB の手前に簡易サーバーをおく?」 でした。
答えは Envoy 経由！まじか。
そしてそのあとの懇親会で、「でもコードを書き変えないで追跡の親子関係の伝播どうやるんだろう」で盛り上がりました。
で調べてみると、Trace context propagation に行き当たり、「入力コンテキストから取り出して、出力に注入する」とか書いてありそう。
まじか…まじなのか。いったいどうやってるんだろう
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 / Rui Ueyama さん
内容の多くは PodCast でお聞きしていたのですが、知らなかったところへ質問した結果、自分の考え方との差分に気がついた、というところでした。
質問は、「既存ツールとのバイナリ差分をなくすことを第一のゴールとしなかったのは、増分開発する方がよかったからですか?」でした。
それに対する回答は以下 3 つです。
特に最後にハッとさせられました。
確かに「調査する時間がないから詳細はわからないけどおまじないとして入れる」とかやっちゃってるんですよね。
でもそれってもしかしたら無駄なものかもしれないのに、全然改善できずそのまま次の人に渡すことになるわけで。
調べ切れる時間を作る、腕を持たねば。
終わりに
振り返ると、もうちょい聞きに行くものの幅を増やした方が良さそうだなーと感じました。
k8s とか microservice あたりに心惹かれたものの、いやそれ聞くなら別の機会があってその時にしよ、と意図的に避けたりしました。が、それでもちょっと実利に寄りすぎな感じでした。
もしくは自分で発表するかか！何をだろ。
Rust と WebAssembly のやつは久しぶりに遊び要素が多めなのであの発展ですかねー
本当にすごいエネルギーであの場を作っていただいていて、感謝しかない感じです。
ありがとう！ builderscon!!
