Kaggleで10年遊んだGrandMasterの振り返り | ho.lc
2011年2月16日に Kaggle アカウントを取得して10年が経過した。長い間 Kaggle Ranking 世界 1 位を目指してきたが、この目標やモチベーションが大きく変化してきたと感じたため、一区切りつけるためにもこの10年+αを振り返る。今の目標は対象を問わずアルゴリズムで資産を最大化すること。エンジニアリングを駆使してデータからアルファを探し、システム化して運用する。実利的で定量評価できる最高に楽しいタスクです（記事では触れません）。 競技プログラミングからKaggleを始めるまで¶ Kaggle ができる前は ICPC や ICFP Programming Contest といった競技プログラミング系のコンテストに参加していた。ICPC ではアジア地区会津大会 2007、アジア地区東京大会 2008 に出場したが大敗して悔しくて仕方がなかった。コードゴルフも嗜む程度に遊んで
Google Cloud の IAM で、開発体制や組織の文化に合わせて検討したこと - Hatena Developer Blog
システムプラットフォーム部で SRE をやっている id:nabeop です。システムプラットフォーム部を一言で表すと、基盤を横断的に見る部署という感じです。 過去の発表などでもたびたび言及していますが、はてなのいくつかのサービスは AWS 上で構築されており、これまで「クラウドに構築する」は「AWS で構築する」とほぼ同義な世界でした。 ただし、AWS 以外も全く使っていなかったわけではなく、小さなプロジェクトや個人では Google Cloud の利用もありました。また最近は、各サービスで技術選択の多様化が進み「Google Cloud 上でサービスを構築する」という選択肢も十分ありえる状態になってきました。 このため、各サービスで Google Cloud の利用が本格化する前に、安心して使えるように IAM (Identity and Access Management) など環境
僕の考えた最強のTUI grepツールを作った - ぴょこぴょこブログ
大きなコードベースを持ったプロジェクトでコードを書くとなった時に、書くのと同じくらい(またはそれ以上に)コードを読むことになると思います。 なので、コードの検索ツールの良し悪しは生産性に直接的に影響してくると言えるでしょう。 VSCode へのお気持ち 僕は普段はIntelliJを使っていて、その検索ツールの出来(もちろんそれ以外も)に非常に満足していますが、諸々の事情からVSCodeを使いたいという気持ちになることが多々あります。 しかし、どうしてもVSCodeの検索ツールが好きになれず移行する気持ちになれないでいました。 具体的に何が好きになれないかと言うと、Open in Editorを使用しない場合は、検索結果の周辺コードのプレビューを見るためにファイルをポコポコ開いていく必要がありツライです。Open in Editorを使用する場合は、周辺コードの情報量の調整が面倒でツライです
時間がかかる複数のCLIタスクをRust製ツールのPueueで管理する
rsyncによる大容量ファイルの転送やDBのバックアップ・リストアなど、たびたび非常に時間がかかるタスクをCLIで実行するシーンがあります。 通常そういった場合は末尾に&を付加(セッションが切れても中断されないようにnohupとセットで使うことも多い)してバックグラウンドで動作させるのが一般的かと思います。 ただ、そのまま使うとログや実行時間、リターンコードなどの採取が面倒であり、いささか一覧性に欠けます。 そんな中、そのようなユースケースに適したPueueという管理ツールが登場しました。 Pueueとは Pueueとは、長時間のCLIタスクに特化したOSSの管理ツールです。 最近はstarshipやnushellといったRust製のツールが勢いを増していますが、例によってPueueもRustによって記述されています。 Pueueの特徴としては、次の通りです。 リッチなUI: バックグラウ
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 - エンジニアHub｜Webエンジニアのキャリアを考える！
カオスエンジニアリングを導入したクックパッドの挑戦 マイクロサービス化に伴う可用性の低下に対応 料理のレシピ投稿・検索サービスのクックパッドでは2年前からカオスエンジニアリングに取り組み、さまざまな事例やノウハウを蓄積しています。クックパッドの技術部・SR（Site Reliability）グループの小杉山拓弥さんとDX（Developer Productivity）グループの鈴木康平さんに、導入の理由やさまざまな知見を伺いました。 カオスエンジニアリング（Chaos Engineering）とは、稼働中のサービスにあえて擬似的な障害を発生させることで、システムの耐障害性を検証する手法です。動画配信サービスを提供するNetflix社が2011年ごろから実践し、ソフトウェアや情報を積極的に公開したことで世界中から注目されるようになりました。 国内ではまだ導入事例も少ないなか、料理のレシピ投稿
CSE 138: Distributed Systems
From the beginning of this year, I started to take lecture courses of undergrad distributed systems course at UC Santa Cruz (CSE 138) by Lindsey Kuper. It consists of 23 lectures (you can see the schedule of topics from here) and recently I’ve finished all of them. I’m not a student at UCSC but due to the COVID-19 situation, all these lectures were delivered online and are available on YouTube. So
MySQLバージョンアップによるInnoDB性能劣化可能性事件簿
一般論ですが、どんな基盤ソフトでもCPUスケールを上げようとすれば、何らかの排他制御を細かく行うことになるのでCPUのパイプライン処理にブレーキをかけるアトミックな処理が増えて、バージョンが上がるとある程度はシングルスレッドの処理は重くなっていきます。前エントリのような言語の高度化により遅くなる事情もあります。（中には、Redisのように並列を捨てて排他処理を完全排除する潔い逆振りプロダクトもありますが。） とはいえ、「これは（条件付きとはいえ）急に遅くなりすぎだろ！」と私も思うバージョン（回避策はある＆一開発者の一存ではどうにもできない）があるので遡って何点か挙げて注意喚起したいと思います。 これらはある程度限られた条件で発生するので世間では怪奇現象扱いされている可能性もあります。 何故こんなことになるのかというと、基盤となるmysqld側の変更に上手くついていけなくなってるか、性能上メ
GitHub - jimblandy/context-switch: Comparison of Rust async and Linux thread context switch time.
These are a few programs that try to measure context switch time and task memory use in various ways. In summary: A context switch takes around 0.2µs between async tasks, versus 1.7µs between kernel threads. But this advantage goes away if the context switch is due to I/O readiness: both converge to 1.7µs. The async advantage also goes away in our microbenchmark if the program is pinned to a singl
Rustの非同期ランタイムが多すぎる？io_uringなやつを使おう！
AWS、Google、Microsoftらが、Rust Foundationを設立し、今やRustでなければクラウドネイティブじゃない、と言っても過言ではありませんよね。クラウドネイティブと言えば、スケーラブルなシステム、Goはgoroutineを標準機能として提供しますが、Rustのasync/awaitは、標準機能に含まれていない外部ライブラリを必要とします。悪いことに、複数のライブラリ（非同期処理ランタイム）が乱立し、APIの互換性もありません。Rustはクラウドネイティブなのだろうか、という疑問を抱きながら、いくつかのランタイムの性能を、いつものgRPCベンチマークで比較してみました。 比較対象数多くのランタイムの中から、前回の記事で試した、Linuxの新しい非同期I/Oインターフェイスのio_uringを利用しているglommioと、普及している思われる、tokio、smol、a
Go+XDPな開発を始めるときに参考になる記事/janog LT フォローアップ - お腹.ヘッタ。
これは JANOG LT のフォローアップブログです。 Go+XDPな開発何も説明できなかったことに気がついたので書きました。 SRv6,GTPv1,XDPの大まかな説明は世の中に神な資料があるので特に説明はしません。 もしebpfとはなんぞなどの疑問がある方は janog 45 パケット処理の独自実装や高速化手法の比較と実践 拙作のブログ: 今日から始めるXDPと取り巻く環境について などを合わせて見ていただけるといいと思います。 TL;TR Go+XDPな開発をしたいなら cilium/ebpf を使うといい https://github.com/takehaya/goxdp-templateという雛形を作ったので始めるときに参考にして欲しい。 GoでXDPをやるときの選択肢と最近の利点 Goを利用する際の開発においての選択肢は以下のようにいくつかあります。 newtools/ebpf
systemtap で udp の daddr, dport が 0.0.0.0 や 0 に見えることがあるのはなんでなのか - エンジニアですよ！
(udp だけど)tcpdump すれば当然宛先の ip address や port が見えるが、systemtap で daddr, dport を printf してみると daddr が 0.0.0.0, dport が 0 に見えることがある。 名前解決のトレースをしていて、通常名前解決をしているときは宛先ポートが 53 になので、 probe udp.sendmsg で if (dport == 53) としておけば名前解決に関係する udp の送信だけトレースできるのだけど、たとえば dig で名前を引いたときにはこれだと引っかからなかったことで気付いた。 実際にトレースしたいプログラムで名前解決が実行される場合は普通に dport == 53 で引っかかるので特に問題はなさそうだが、どういうケースで 0 になってしまうのか確認した。 結論から言うと、(正確にはわかっていない
eBPFでQUICパケットをルーティングしていく - Qiita
はじめに LinuxのeBPFを使ってQUICパケットのDestination Connection IDを元にQUICサーバーのSO_REUSEPORTした特定のソケットへパケットを送り込む試みについて記述します。 ユースケース TCPを扱う典型的なマルチスレッドサーバーの一例としては、各スレッドでlisten、受信データの処理を行います。カーネルがパケットの面倒は全て見てくれるため、アプリケーションはソケットからデータの送受信だけをしていれば良かったのです。QUICはUDPパケットのハンドリングはカーネル任せですがその先は、ユーザースペースで実装する必要があります。UDPでSO_REUSEPORTを使って複数ソケットで同じアドレスで待ち受けすることはできますが、IPアドレス、ポートの四つ組で振り分けされることになります。QUICは概ねこれでも行けそうですが、QUICはコネクションのマイ
eBPF: BPF_MAP_TYPE_SK_STORAGE が Invalid argument - Unyablog.
Linux の eBPF で BPF_MAP_TYPE_SK_STORAGE を使おうとして、map を定義して bpftool で流し込んだけど Invalid argument でうまく動かなかった。調べてもヒットしなくて長時間費やしたのでメモ。 環境は ArchLinux で Kernel release は 5.7.10-arch1-1。 TL;DR BTF に対応する必要がある。 詳細 struct bpf_map_def SEC("maps") sk_storage_map = { .type = BPF_MAP_TYPE_SK_STORAGE, .map_flags = BPF_F_NO_PREALLOC, .key_size = sizeof(int), .value_size = sizeof(int), }; このような map を作って、それを使ったプログラムを lo
開発チームとともに歩むSREチームが成し遂げたいこと | メルカリエンジニアリング
こんにちは、メルカリMicroservices SREチームでEngineering Managerをしている@m4buyaこと渋谷です。 メルカリでは、昨年6月にSREチームの一部をマイナーアップデートし、プロダクトチームに寄り添いSREとしての専門性を活かし信頼性に貢献していくMicroservices SREチームを発足しました。本記事では、そうするに至った背景、何を目指しているのか、これまでに出来たこととまだ出来ていないことを振り返り、今後の展望についてご紹介します。 背景 メルカリでは、2015年よりSREチームを立ち上げ、お客様が安心・安全にメルカリサービスを利用していただくためのシステムの信頼性の維持向上に取り組んできました。年々プロダクトとして成長を続け、トラフィックも増加する一方のメルカリサービスに求められるスケーラビリティ向上において、メルカリSREチームは大きな役割を
eBPF Updates #3: Atomics Operations, Socket Options Retrieval, Syscall Tracing Benchmarks, eBPF in the Supply Chain
eBPF Updates #3: Atomics Operations, Socket Options Retrieval, Syscall Tracing Benchmarks, eBPF in the Supply Chain With the festive season, it would seem that eBPF blogging has cooled down a little, and we have fewer items to report this time. But eBPF is getting traction everywhere, so we can be confident that more material will be available for the months to come. Let's wager that 2021 will be
API Gateway + Lambda + Rust で開発する (2021-01) - eagletmt's blog
まとめ netlify_lambda を使う Lambda の Docker イメージサポートを利用する aws-lambda-rie-gateway を使う この構成で Slack の interactive message や block kit で遊んだサンプルがこれ https://github.com/eagletmt/misc/tree/master/rust/slack-slash-command-sample Rust 向けの Lambda Runtime lambda-runtime という準(?)公式の crate がある https://github.com/awslabs/aws-lambda-rust-runtime が、リリースが滞っている。 現在リリースされている中での最新版では async/await の対応すら入っておらず、現在の Rust では正直使い物
はてなで働き始めてからほぼ5年になるので振り返ってみる - yasuhisa's blog
そろそろ前職を退職してから、はてなで働き始めて5年(!)が経とうとしている。5年も働いていると、昔何をやっていたか、その当時どういう気持ちで働いていたかを忘れてしまう。備忘録っぽく書き残しておこう。ポエムです、長いです、大体自分向けに書いてる。 NTT CS研 => 株式会社はてな チーム開発への適応 インフラ苦手意識の克服 教師なし機械学習の本番環境での運用 データ基盤とCustomer Reliability Engineerへの挑戦 今後はデータエンジニアリング NTT CS研 => 株式会社はてな 基礎研究職からWebアプリケーションエンジニアへの転職だった。ログを残しておくと、こういう時に振り返れて便利。 NTT CS研を退職して、株式会社はてなに入社しました - yasuhisa's blog 割と珍しい(?)転職ではあったかもしれないが、機械学習や自然言語処理はアルゴリズム単
企業研究者の立場からKaggleに取り組む意義を考えた - Fire Engine
先日，Kaggleで初めてコンペに挑戦し，その振り返りをブログに書きました． 現在，企業で研究者として働いている私は，Kaggleのコンペに取り組むことは非常に学びが多く，自身の研究活動にも良い貢献をするだろうと確信しました． 私自身Kaggleに取り組むまでKaggleと研究に繋がりを見いだせておらず，実際にコンペに取り組むことでその繋がりが見えてきました． まだ1コンペしか参加経験がないビギナーではありますが，私が考えている研究者としてKaggleに取り組む意義について現時点の考えをまとめたいと思います． 自分の立場について Kaggleへの取り組みが研究に良い貢献をするかどうかは，研究の分野や内容に依存すると思うので，私の立場をはっきりさせておきます． 私は現在，インターネットインフラサービスを提供するさくらインターネット株式会社の組織内研究所であるさくらインターネット研究所で研究員
さくらインターネット研究所、情報処理学会のシンポジウムにて4賞受賞 | さくらインターネット
さくらインターネット研究所、情報処理学会のシンポジウムにて4賞受賞 〜所員の論文および公立はこだて未来大学との共同研究〜 インターネットインフラサービスを提供するさくらインターネット株式会社（本社：大阪府大阪市、代表取締役社長：田中 邦裕）の組織内研究所であるさくらインターネット研究所に所属する所員の論文が、情報処理学会「第13回インターネットと運用技術シンポジウム」において優秀論文賞と優秀プレゼンテーション賞を受賞いたしました。 さらに公立大学法人公立はこだて未来大学（所在地：北海道函館市、理事長：片桐 恭弘、以下「公立はこだて未来大学」）との共同研究内容が「第13回インターネットと運用技術シンポジウム」において優秀ポスター賞、「第32回コンピュータシステム・シンポジウム」において最優秀若手発表賞を受賞いたしました。 受賞した論文は以下の3本です。いずれの論文も、より快適・安全にインター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - goldshtn/linux-tracing-workshop: Examples and hands-on labs for Linux tracing tools workshops
