情報更新

last update 03/31 17:15

ツイート検索

 

@mumoshu
サイトメニュー
Twilogユーザー検索

Twilog

 

@mumoshu

Yusuke KUOKA@mumoshu

Stats Twitter歴
4,309日(2008/06/14より)
ツイート数
74,752(17.3件/日)

ツイートの並び順 :

表示するツイート :

2020年03月27日(金)1 tweetsource

2020年03月24日(火)6 tweetssource

2020年03月23日(月)1 tweetsource

2020年03月22日(日)16 tweetssource

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

Rustの関数への&mut渡しはwrite権付きの借用で、&はreadのみの借用で、値渡しは所有権のmove、closureの場合はmoveされてなければ関数の環境を借用、moveされてれば関数の環境のコピーの所有権を取る、って感じ?

posted at 11:43:43

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

preempt_check! をコンパイラがよしなに必要な箇所に自動的に追加してくれるようになったら、だいたい Go routineと同じような気持ちで使えるようになるかな

posted at 11:07:36

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

じゃあブロッキングな処理は単にspawnに入れておけばよいかというと、そうでもない。spawn中のタスクがブロックしてる間はtokioのランタイム(executorかな)のスレッドはブロックされる。その時間が長いと、他のspawnされたタスクがそれだけ実行されない。

posted at 11:03:49

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

try_join!の説明にも、ブロッキングな処理の場合はspawnの利用が勧められてる。spawnはtokioのランタイムに処理をスケジュールして、直ちにJoinHandleを返す。JoinHandleがFutureを実装している。

posted at 10:55:51

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

Tokioのtry_join! のように複数のfutureを並行に評価してくれる・・ように見えるものでも、実体が複数のfutureのpollをカレンドスレッドで順番に呼び出すみたいな実装になってる。結局どれかのpollがブロックするとtry_join!自体もブロックして並列どころが並行にすらならないかもしれない。

posted at 10:52:22

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

async fnはFutureを返すようだが、async fn中の処理はpollで実行される模様。なのでasync fn中でawaitしないような処理を長々やると、その間pollの呼び出し元スレッドがブロックする。

posted at 10:50:09

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

そういうfutureは、future.awaitを呼び出したときに暗黙的にpollされる。futureの実装は、poll中で速やかにPendingかReadyを返すことが求められる。そうじゃないと、pollを呼び出したスレッドをブロックしてしまうから。

posted at 10:42:30

3月22日

@mumoshu

Yusuke KUOKA@mumoshu

当たり前だけど、Futureと、非同期処理の実行を司るランタイムは何も関係ない。そのため、futureが作られただけでは何も処理が実行されないことが多い(実のところ、futureを返すライブラリの作り次第だと思うが)。

posted at 10:40:45

2020年03月20日(金)1 tweetsource

2020年03月09日(月)2 tweetssource

2020年03月05日(木)1 tweetsource

2020年03月04日(水)1 tweetsource

2020年03月03日(火)5 tweetssource

3月3日

@mumoshu

Yusuke KUOKA@mumoshu

Fluentdみたいに設定によってノードの特定の箇所にposファイルをつくるようなアプリはこれだと競合してうまくいかなそうだけど、例えば Ingress Controller の類をDaemonSetでデプロイしているような場合はばっちり動きそう。よさみを感じる。

posted at 20:52:03

3月3日

@mumoshu

Yusuke KUOKA@mumoshu

Fluentdみたいに設定によってノードの特定の箇所にposファイルをつくるようなアプリはこれだと競合してうまくいかなそうだけど、例えば Ingress Controller の類をDaemonSetでデプロイしているような場合はばっちり動きそう。よさみを感じる。

posted at 20:50:05

2020年02月21日(金)1 tweetsource

2020年02月20日(木)5 tweetssource

2月20日

@mumoshu

Yusuke KUOKA@mumoshu

helmfileみたいに宣言的にデプロイを順序立てる方法はFluxやArgoCDには無いものと思ってたけど、ArgoCDにはあった。

helmfile内の順序からArgoCDのsync-wave値を計算してエクスポートするような機能つけようかな

posted at 09:33:00

2月20日

@mumoshu

Yusuke KUOKA@mumoshu

Sync Waveの使いどころは、複数のマイクロサービスを特定の順序でデプロイしたい、というような場合。CIからデプロイするときはkubectl apply && waitを順番にやればいいけど、ArgoCDではどうするか。「sync-wave: 数値」で優先順位づけすれば、数値の小さい順にapply & waitしてくれる。

posted at 09:30:58

2020年02月19日(水)4 tweetssource

2月19日

@mumoshu

Yusuke KUOKA@mumoshu

アプリケーション自体のデプロイメントと、設定のデプロイメントを同時にやろうと思えばやれちゃう点も一緒かな。

アプリケーションの修正に対してはCodeDeploy、設定の修正に対してはAppConfigデプロイをトリガするようなデプロイパイプラインを組んでおくとよさそう〜。

posted at 09:44:52

2月19日

@mumoshu

Yusuke KUOKA@mumoshu

「CodeDeployとかぶってるやん」と思ったけど、設定値のデプロイにはAppConfig、コードの配布にはCodeDeployというふうに使い分けるといいのかなぁ。K8sでいうConfigMapボリューム感ある。

posted at 09:43:37

2020年02月13日(木)1 tweetsource

2020年02月10日(月)4 tweetssource

2月10日

@mumoshu

Yusuke KUOKA@mumoshu

@kompiro あったら便利そうですね〜!

WatchというAPIがあって、それ使うとDeploymentなどに対して発生したイベントをkubectlやclient-goで受けることはできます。それがここでいうLifecycle Hookみたいなものかな〜と思いました

posted at 15:57:20

2020年02月07日(金)2 tweetssource

2月7日

@mumoshu

Yusuke KUOKA@mumoshu

前段がALB限定なので、HTTP/2のワークロードには使えないし、ロールバックはCloudWatch Alarm起因しかできない(だろうなとは思っていたけど)のは前提として。

posted at 10:07:10

2月7日

@mumoshu

Yusuke KUOKA@mumoshu

ECSのCanary Deployment、Canaryにトラフィックを流す前のテスト(lifecycle hook)と、流したあとのテスト(cloudwatch alarm)にもちゃんと対応してるぽい。だいたいEKS + Flaggerと同じことができるという理解でいいか。

posted at 10:05:45

このページの先頭へ