When a Java application runs, the JVM goes through the process of loading, initializing, and optimizing the code used by the application, including libraries, frameworks, and other components to reach the optimal performance level. Each time the application restarts, it has no record or memory of previous times it has run and the work it performed. As a result, it has to restart, extending valuabl

This past month, I have been enthralled by the Rust programming language given its unique edge for writing memory-safe, modern programs. Over the years, several languages have emerged as the most preferred by engineers to write resilient, backend software. The tides have shifted from Java/C++ into Go and Rust, which combine decades of programming language theory to build tools that are effective i

Webhooks are the foundation of modern API development. They enable us to react to changes in our systems, an incoming text message, a successful payment, or that latest pull request no matter our stack. While webhooks are universal in concept, they are unstandardized API contracts with few organizations paying attention to their design, security controls, and overall operational experience. Webhoo

Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。植山氏は、制作中のリンカである「mold」について発表しました。全2回。前半は、リンカの概要について話しました。 LLVMのリンカ「lld」オリジナルの作者 植山類氏：植山類です。今僕が作っているmoldというリンカについて発表します。 今回の発表の概要です。リンカが何かを知っている人はそんなにたくさんいないと思うので、まず説明します。次に、「mold」のポイントは速いことなのですが、速いと何がうれしいのかを説明します。そのあと、どれくらい速いのかを説明した上で、どう実現されているのか、概要を紹介します。詳細になると何時間あっても終わらないので、かなりハイレベルな話をします。 自己紹介のスライドを入れていませんが、僕はリンカを何度か作ったことがあって、LLVMのlld

はじめに 皆さんこんにちは．3回生のらん（@hoshina350）です． 文字列マッチングに便利な正規表現ですが，テキトーに書くと脆弱になり得るという情報を耳にしてから色々と原因や対策を調べていました． しかし，多くの記事で紹介されていた対策方法は，「独自の正規表現を使用しないー」とか「 * や + などの繰り返し表現はなるべく使わないー」とかいう なんともふわっとしたものでした．これでは「いやぁ確かにそうなんかもしれんけど…そうゆう訳にはいかんやんか…」と納得できません． つまり，「本質的に何が問題」で，「具体的にどんな特徴のある正規表現が脆弱になり得るのか」を知りたい訳です． そこで，様々な文献を調査してみました．本記事では調査して溜まった知見を紹介していきます． 本記事は， Purdue大学のJames Davis教授による “The Regular Expression Denia

初めに サイボウズ・ラボの光成です。 いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。 ビットコインでは相手の公開鍵を用いてハッシュ値を暗号化して相手に送る。 TLS1.3ではサーバ公開鍵を用いてAESの秘密鍵を暗号化する。 答えはどれも間違いです。 公開鍵認証は、(デジタル)署名を使って相手先の正しさを検証するものであり、暗号化は行われません。 同様にビットコインもデータや相手の正当性を確認するために署名が用いられ、暗号化は行われません。 TLS 1.3ではRSA暗号の公開鍵を用いて暗号化する方式(static RSA)は廃止され、ECDH鍵共有された値を元に秘密鍵を生成し、AES-GCMなどの認証つき暗号で暗号化します。 公開鍵暗号とは いわゆる公開鍵暗号には大きく2種類の意味があ

イラストで正しく理解するTLS 1.3の暗号技術 初めに ここではTLS 1.3（以下TLSと略記）で使われている暗号技術を解説します。 主眼はTLSのプロトコルではなく、「暗号技術」の用語の挙動（何を入力して何を出力するのか）と目的の理解です。 実際にどのような方式なのかといった、より詳しい説明は拙著『図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』（暗認本）や『暗認本』の内容を紹介したスライドや動画などの資料集をごらんください。 なお表題の「イラストで」は数式を使わないという程度の意味です。 TLSで守りたいもの TLSはコンピュータ同士が安全に通信するための規格です。 主に人がブラウザを介して「https://」で始まるWebサイトにアクセスするときに利用されます。 安全に通信するためには、通信内容が盗聴されても情報が漏れない機密性が必要です。 それから通信が改

Why replace ZooKeeper with an internal log for Apache Kafka® metadata management? This post explores the rationale behind the replacement, examines why a quorum-based consensus protocol like Raft was utilized and altered to become KRaft, and describes the new Quorum Controller built on top of KRaft protocols. Why replace ZooKeeper? In 2012, work was underway to begin implementing the current exist

4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー

CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

こんにちは、テクニカルトレーナー/マネージャーの西村 (@kuwablo) です。 AWS トレーニングのトレーナーを担当しつつ、お客様の AWS 学習を支援する記事を公式ブログや builders.flash に投稿し、チームメンバーのマネジメント業務も合わせて行っています。 突然ですが、皆さんは普段の仕事でネットワーク機器の設計や保守などは担当していますか ?「ルーターはマシンルームで見たことはあるけど触ったことはない。」「アプセトネデブ (OSI 参照モデルの 7 つの階層の暗記術) とか昔ちょっと勉強したけど忘れちゃったな。」という方から「俺はネットワーク生まれデータセンター育ち」という方までいらっしゃると思います。 私がトレーニングを実施する際に「自分のチームのメンバーにネットワークを勉強してもらいたいんだけど、何か良い方法ありますか ?」「アプリ開発者ですがインフラを体系的に勉

HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。 IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能（最初のデータが到達するまでの時間、通信終了までの時間やスループット）、ネットワークへのオーバーヘッド（バイト量とパケット数）、リソースの使用状況（CPU使用率、RAM使用量）、の3つを比較しています。 性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。 これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。 元論文は下で読めます。 arxiv.org 実装について H3 pub-s