サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
syucream.hatenablog.jp
みなさんいかがお過ごしでしょうか。 @syu_cream です。 わたしは半年ほど前にユビー株式会社へソフトウェアエンジニア(以下 SWE)として転職しています。転職前後のストーリーは以下のエントリにて紹介しています。 syucream.hatenablog.jp 本記事では入社から半年後にかけての展開について綴ろうと思います。 ユビーの SWE について まず自分が在籍する、ユビーの SWE というポジションについて触れておきます。 昨今のテック企業では選考の間に技術面接を経てポジションにマッチする技術力を持っているかを評価するケースが多々あると思われますが、ユビーではこのような技術面接は行っていません。その代わりに、特定の技術スタックへの理解が深いかどうかなどは問わず、プロダクト開発に欠かせない素養があるかを確認するため面接を設けています。この面接の体系についてはより詳しくまとめた記事
表題の通りで、 2021年7月より前職の株式会社メルペイ(メルカリ)を退職して Ubie に転職しました。というわけでいわゆる転職エントリです。 TL;DR メルカリ・メルペイに 3 年 10 ヶ月在籍しました スキルや経験の幅を持たせたい、サービス初期の雰囲気をまた味わいたくて転職 Ubie に入社して SWE として働き出して一ヶ月経過しました メルカリ・メルペイでやってたこと メルカリには 2017 年 8 月に入社し、約半年間 SRE チームに所属していました。その後メルペイの立ち上げに合わせて異動して 2021 年 6 月末までデータエンジニアをやっていました。本当に数多くの同僚や関係者に恵まれておりました。お世話になった方々ありがとうございました。 メルカリ・メルペイで体験したことは枚挙に暇がなく、約 4 年で体験したことなのかと疑うほどに濃密なものでした。プロ集団の SRE
分散アプリケーション間のメッセージングやログ収集基盤において、しばしばスキーマの扱いは便利である反面頭を悩ませる種になります。 スキーマを厳密に定義して、 Protocol Buffers や Avro などのシリアライゼーションフォーマットを用いることで、メッセージのサイズの減少やメッセージの扱いの安全性を実行時より早く検出できる機会が増えます。 しかしスキーマの互換性に気をつけたり、メッセージをシリアライズ・デシリアライズするアプリケーション間でスキーマ情報をどう共有するかの課題も発生します。 この課題は、昨年発売された "データ指向アプリケーションデザイン" でも "4.1.4.3 そもそもライターのスキーマとは何なのか?" などで触れられています。 世の中にはこの課題を解決するための "スキーマレジストリ" と呼ばれるソフトウェア、サービスがいくつか存在します。 残念ながら日本語の
一年以上前の記事だけど、 https://martinfowler.com/ に "Data Mesh" をうたう記事があったので軽く読みました。 martinfowler.com こちらに日本語で概要をまとめた記事もありご一読することをおすすめします。 僕の個人ブログを見るより確実で良い情報を得られるでしょう。 https://www.infoq.com/jp/news/2020/03/distributed-data-mesh/ 以下では現行のぼくの業務と照らし合わせて、 Data Mesh について個人的解釈などを書いていきます。 Current status ... 二年くらい前に builderscon で "メルペイにおける、マイクロサービスに寄り添うログ収集基盤" みたいなタイトルで LT で発表したりしました。 当時、急速に開発されるマイクロサービス群と元から存在したモノリ
Apache Avro になにかと縁があり、かつ普及しているテクノロジーの割に日本語の情報がそんなにない(個人の意見です、意外とあるかも)のでつらつら書いてみます。 整理はされておらずシーケンシャルに要素を並べています。 実装についてとくに言及がされていなければ、 Java の 1.8.2 について触れているものとします。 Apache Avro はデータフォーマットとエコシステムのひとつ Apache Avro は Apache トップレベルプロジェクトのひとつでファイルフォーマットとその周辺エコシステムです。 比較される技術として Protocol Buffers や Message Pack が挙げられると思います。 Apache Avro はそれらの中でも主に Hadoop エコシステムなどビッグデータ絡みの文脈でよく登場するように思えます。 以下のディレクトリ構成の通り、公式でい
この記事は Kubernetes2 Advent Calendar 4 日目の記事です。 本記事は CSI(Container Storage Interface) と Kubernetes での CSI のサポートについて触れます。 執筆に時間があまり割けなかった為、後でもう少し加筆する、あるいは別途続きの記事を書くかもしれません。 CSI(Container Storage Interface) とは CSI(Container Storage Interface, 以下 CSI) は Kubernetes など複数の Container Orchestration (CO) から共通のプラグインを使って SP (Storage Provider) とやり取りするためのインタフェース仕様です。 より具体的には、 CO からストレージを抽象化した Volume をアタッチ・デタッチしたり
Netflix はマイクロサービスアーキテクチャ界においてプロダクションで成功例を積んでいる、いわば大先輩だと思われます。 彼らは数多くのイベント登壇や techblog の記事、 GitHub 上による OSS の公開を行っており、それらからアーキテクチャやその変遷を垣間見ることができると考えています。 本記事では筆者が最近悩んでいる、マイクロサービス前提の世界でのログ収集基盤において、 Netflix の様々な事例を調べた結果をつらつら書いていこうと思います。 あらかじめ本記事は正確性を担保しておらず、あくまで筆者個人が調べることができた範囲での記述に留まることをお断りさせていただきます。 Suro: 分散データパイプライン 2015 年くらいにメンテが止まってしまったのですが、分散データパイプラインをうたう Suro というソフトウェアが存在しました。 Suro に関しては解説記事も
ちょうど一年前の 2017年8月16日に株式会社メルカリに入社しました。キリがいいこともあり、ここらで個人的な振り返りをつらつら書いてみます。あらかじめ、はっきりいって個人の日記レベルの内容であることをお断りさせていただきます。 転職の経緯から入社まで 2017 年 1 月頃から転職を考え初めていました。元の所属も Web サービスをなりわいとしており、それなりの愛着もあり良い経験をさせて頂いてはいたのですが、自分の能力向上を目指しつつより早いペースでプロダクトを提供していく体験を積みたく粛々と準備をしていました。 そんな中メルカリは、急成長しているサービスを提供しており外部への発信も多く、また所属エンジニアも強力な方々が多く自分にとっても良い経験になると踏んだため応募した次第でした。 応募に際して僕の場合は特に知り合いのツテやエージェントを通さずに、採用ページの募集フォームにダイレクトア
以下の記事でご紹介した、弊サークルの技術書典4の新刊を GitHub で public repo として公開しました。 syucream.hatenablog.jp リポジトリはこちらになります。 github.com ビルド済み pdf は無く、またその他配布した原稿にしか含まれないコンテンツなどあるかもしれませんが、ご了承ください。 技術書典4振り返り いい機会なので振り返りをつらつら書きます 執筆環境について Re:VIEW で原稿を記述 CircleCI で textlint 実行と pdf 自動ビルドするようにした 入稿直前になって pdf がコレジャナイ感出るのマジ勘弁!なので base の Docker Image に vvakame/review を使わせていただきました 細かなレビューは GitHub の pullreq or Issue ベースで実施 進捗管理について
GW 中の自分へのプチ課題として、表題の通りのツール hakagi(葉鍵, Leaf and Key) を作りました。ツール名には特に意味はありません。 github.com テーブル名やカラム名から外部キー制約を張れるような気がするカラムを選出し、制約追加のための ALTER TABLE をするクエリを吐き出したりします。 なぜ作ったのか 外部キー制約は言うまでもなくデータの不整合を避けるのに有用ですが、いくつかの理由からこれを用いない選択肢も存在すると思われます。 この辺りについては以下の記事なども参考にすると良さそうです。 我々(主語が大きい)は何故MySQLで外部キーを使わないのか MySQLで外部キー制約を課すべきか - リジェクトされました 外部キー制約を設けないことによるデメリットも幾つか生じると思っていて、その一つで自分が気になっている点として、「ER 図をツールで自動生成
あけましておめでとうございます。年末年始はほぼ寝て過ごしていました。 表題の通り、去年に 第1回WSA研究会 というイベントに参加したのでその振り返りなどをさくっと書いていきます。 第1回WSA研究会全体への雑感 発表内容は以下の通りで、名前の通り Web System Architecture の体系化や選定、流行りの Microservices 、ストレージに関する内容が多かった印象です。 websystemarchitecture.hatenablog.jp イベント中ははてなさんの会議室の一角を利用して割と近い距離感のなか発表者が事前準備したスライドと共に発表し、聴衆が様々なコメントをしていく形式です。 発表時間15分,質疑応答15分というスケジュールのなか、発表自体も質疑もなかなかの盛り上がりをみせ、充実した時間になったのではないかと感じます。 このイベントで個人的に興味深かった
第1回WSA研究会 という催し物に出る予定でそれ用の予稿を書いたのですが、折角なのでブログにも掲載しておこうと思います。あとで更新するかもです。 再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み Infrastructure as code や CI/CD の文化の広がりやインフラ構成の複雑化に伴い、 Test Driven Infrastructure といったインフラ構成をテスト可能にすることで安定稼働を目指す取り組みがなされている。 Test Driven Infrastructure の実践方法としては 1) Ansible や Chef などといった構成管理ツールに特化したテストツールを使う 2) Serverspec などといった構成管理ツールとは独立したツールを使う方針が考えられるが、前者はツールに非常に依存しかつ独特の DSL を
TLDR 重複行を除去する uniq コマンドを早く実行するツール "quniq" を Go で作ってみました。 github.com 自分が測った限りでは、他の重複除去を行なうワンライナーと比べて、処理に要する時間が少なくとも 1/3 程度になることが確認できました。 背景 みなさまご存知の通り、 uniq はソート済みの入力を受け付けて重複行を除いた出力を吐き出すツールです。 また -c オプションで重複件数も出力したりすることが可能です。 特に集計の前処理として余分な行を除外したり、アクセスログ中の特定要素のランキング化に利用されることが多いように感じます。 uniq はソート済みの入力を期待するためよく cat /path/to/file | sort | uniq のように sort した結果をパイプで渡すことが多いと思うのですが、入力のサイズが大きくなってくると sort に時
Apache Beam データに対する ETL 処理を、様々なランタイムで同じコードで実行できるようにするものです。 これは Google Cloud Dataflow のモデルを元に OSS 化されたもので、バッチ処理とストリーム処理を(ほぼ)同じコードで実装できたり、 Hadoop や Spark 、 Dataflow など複数の実行環境に対応していたりします。 標準では Java と Python 向けの SDK が用意されていますが、前者はシンタックスが独特であり後者はまだ機能が乏しく、発展途上感が否めない部分があります。 本記事では Java SDK をラップしつつ機能追加をされた、 Spotify 製ライブラリ Scio を使って Apache Beam による ETL 処理の実装に入門してみようと思います。 そもそも標準の SDK はどんな感じ? 公式ページのドキュメント が
ながすぎる;よんでない リポジトリは以下にあります。 本体 https://github.com/syucream/sssspec 関連 mrbgems https://github.com/syucream/mruby-rspec https://github.com/syucream/mruby-serverspec 以下のように spec を書いて… def __main__(argv) describe file('mrblib') do it { should be_readable.by('yourgroup').by_user('you') } end end sssspec をビルドして… $ rake 生成されたバイナリひとつで spec を実行することができます $ ./sssspec . Total: 1 OK: 1 KO: 0 Crash: 0 Time: 0.16
この記事は mruby Advent Calendar 2016 26 日目の記事です。・・・というのは嘘です! mruby Advent Calendar 2016 、つつがなく完走しましたね!みなさまお疲れ様でした! 本記事では表題の通り、 mruby-k2hash という mgem を作ってみたことに関する共有になります。 K2HASH とは K2HASH は Yahoo! JAPANのブログ でちょろっと紹介されている KVS です。 ソースコードは GitHub で閲覧することができます。 上記の記事では簡潔な紹介のみになっていますが、 GitHub の wiki を読む限り下記の点から興味深いプロダクトなような気がします。 プラグインで拡張可能なトランザクション サブキーによる階層化されたデータ構造 更新処理のアーカイブ化 キュー管理機能 有効期限などといった属性情報 こうして
この記事は mruby Advent Calendar 2016 11 日目の記事です。 Advent Calendar のネタとしてはやっぱりイカした mrbgem を作りました的な内容をブチ上げて行きたいところですが、残念ながらそのようなネタは思いつかず。 本記事では自分が拙作プロダクト ts_mruby を実装中ハマった問題をちょろっと共有するシンプルな内容になっています。 背景 ことのおこり ts_mruby は Apache Traffic Server(以下ATS) に組み込むプラグインとして、 mod_mruby, ngx_mruby のような役割を担うことを目的に開発を続けています。 また、今年 9 月に バージョン 0.1 をリリースしています。 ATS は主な用途が HTTP プロキシサーバであり、プラグイン向けにいくつかのフックが用意されています。 ts_mruby-
こんにちは。一番好きな Key 作品は Air です。 本記事では draft-ietf-httpbis-key-01 - The Key HTTP Response Header Field により定義される、 "Key" という HTTP ヘッダフィールドによって実現されるセカンダリキャッシュキーの処理を、拙作プロダクト ts_mruby を用いて mruby で実装してみた体験などについて記述します。 ts_mruby 自体や、関連技術である Apache Traffic Server(ATS) 、はたまた mruby については本記事では詳しくは触れません。もしよろしければ、 僕が以前執筆したブログエントリ や巷のイイカンジの記事など参考にしていただければ幸いです。 順序としては 1) 前述の I-D で定義される Key ヘッダについて簡単に説明を行い、 2) ts_mruby
(English version is here.) このブログで何度か紹介している、 Apache Traffic Server(ATS) の設定やちょっとした制御ロジックを mruby で記載することを可能にするプラグイン、 ts_mruby の 0.1 バージョンをリリースしました。 せっかくなので本記事ではその 0.1 の機能やできることについてつらつらと書いていき、今後の課題についても述べてみます。 ts_mruby-0.1 0.1 ってなんだよ!なにをもって 0.1 とバージョン切ってるんだ!という感じですが、ぶっちゃけ明確な基準が存在しません() ngx_mruby でできるようなことが ATS でもできると良いと考えていた都合もあり、 ngx_mruby の example と似たようなことがある程度出来るようになったら一区切りとしていました。 ts_mruby-0.1 で
今日は夏コミのようですね!僕は今年は特に原稿を描いておらず用事も無いためコミケに縁のない夏を過ごしてしまいました。 ところで最近拙作の ATS(Apache Traffic Server) プラグインである ts_mruby にレスポンスボディをいじくるメソッドを追加し、ふと思い立って画像リサイズのロジックを mruby で書いてみました。 そのレスポンスボディ加工メソッドは ATS::Filter#transform! になります。 このメソッドではブロックまたは Proc オブジェクトを渡すとブロックパラメータに加工前のレスポンスボディが渡され、評価値でレスポンスボディを差し替えます。 f = ATS::Filter.new f.transform! do |body| # append text to the end of response body body + "rewritte
はじめに 本記事は http2 Advent Calendar 2015 の 12 日目の記事となります。 本記事では HTTP/2 における TCP コネクション再利用とその周辺仕様を確認してみようと思います。コネクション再利用の挙動を理解することは、実際の Web サイトにおける HTTP/2 のデプロイの助けになると思われます。 HTTP/1.1, HTTP/2 での TCP コネクション管理 よく訓練された方々には既知のことかとは思いますが、 HTTP/2 において HTTP/1.1 の頃にあった性能向上の為のハックであるドメインシャーディングは好ましくないテクニックになってしまいます。 HTTP/1.1 において今日のブラウザは 1 ドメインあたり概ね 6 TCP コネクションほど張って、並列にリクエストを送るような振る舞いをします。このため Web サイトなどで参照するドメイン
mod_mruby や ngx_mruby 、 h2o_mruby 、 libvmod_mruby など、さまざまな HTTP サーバの設定などを mruby スクリプトで書ける世の中になりつつありますね。 そんな風潮の後押しもあり、近頃、題意の通り mruby で ATS(Apache Traffic Server) の設定やヘッダの加工などのロジックを mruby で記述可能にするプラグイン、 ts_mruby をちまちまと開発しています。 ts_mruby によって例えば下記のようなロジックが mruby で書けるようになります。 リクエストヘッダを付与したり削除する if server_name == "NGINX" Server = Nginx elsif server_name == "Apache" Server = Apache elsif server_name == "
表題の通り、 RFC7541 "HPACK: Header Compression for HTTP/2" の 日本語訳されたドキュメント を公開しました。 今のところ GitHub の僕のリポジトリにて編集管理を行っています。(将来的には別の管理の仕方をするかもしれません) 前回日本語訳を行った時点(draft-10) から RFC になるまでの、記述上の細かい修正の追従が主になります。また、前回イマイチだった箇所の日本語訳も少し修正しています。 問題点の指摘や翻訳の改善の Pull-Request 、大歓迎です。 こちら よりお願いします。 末筆ですが、やっと HTTP/2 , HPACK の RFC が出ましたね!これまで変更を追従してきた皆様お疲れ様でした。
表題の通り、 HPACK draft10 の日本語訳されたドキュメント を公開しました。 今のところ GitHub の僕のリポジトリにて編集管理を行っています。(将来的には別の管理の仕方をするかもしれません) 問題点の指摘や翻訳の改善の Pull-Request 、大歓迎です。こちら よりお願いします。
本稿は HTTP2 Advent Calendar 2014 20 日目の記事です。 本稿では HTTP/2 周辺のトピックでもやや地味な部類に入るであろう、 HTTP Alternative Services について簡単に触れていきます。 2014-12-21 19:20 用語の修正 概要 HTTP Alternative Services とは、 HTTP で配信するリソースを他のプロトコル、ホスト、ポート番号でもサービス提供ができることを通知する仕組みです。 用途としては下記のようなものが想定されます。 メンテナンス等のためサーバをダウンさせる前に、他のサービス可能なサーバを提示する 新しいプロトコルへの切り替えを提案する(HTTP/1.1 から HTTP/2 へ、など) 日和見暗号(サーバ認証を行わず http スキームで暗号化通信する仕組み) の使用を提案する SNI などをサ
はじめに 本稿は システム系論文紹介 Advent Calendar 2014 14 日目の記事です。 Maygh: Building a CDN from client web browsers (EuroSys'13) という論文を読みました。ざっくりと内容紹介や所感を記述します。 概要 Maygh は Web ページで要求される静的リソースを、既にそのリソースを持っている他のクライアントから P2P 通信で受け取ることによりサーバ側の帯域使用量を低減するシステムです。 Maygh は JavaScript で記述されたクライアントスクリプトという形でユーザに提供され、 WebRTC などを使ってクライアント間通信を実現します。その他専用のブラウザのプラグインなどを導入する必要はありません。 ただしコンテンツ配信者は coordinator と呼ばれるキャッシュ保持情報と保持するクライ
今日よく使われるWebブラウザは、ドメイン毎に複数コネクションを張ってWebページの表示までにかかる時間を短縮しています。 この同時接続数については、 High Performance Browser Networking では 6 個だと書かれています。(この値はブラウザの実装依存なところがあり、IE11では 13 個同時にコネクションを張りうるらしいです。また、この値は Firefox であれば about:config から変更が可能なようです。) そもそも仕様ではどうなっているのかというと、 RFC 2616 では 8.1.4 Practical Considerations にて下記のような記述があります。 Clients that use persistent connections SHOULD limit the number of simultaneous connect
このエントリは、 カーネル/VM Advent Calendar 2013 の 19日目の記事として書いています。 こんにちは、 @syu_cream です。 本記事では SSD に特化したファイルシステムであるところのF2FS(Flash-Friendly File System) の軽い説明を入れつつ、試しに使ってみて軽くベンチマークを取ってみた結果を掲載します。 大分ざっくりと書いてるので、誤った点など多々あるかと思います。適当にご指摘頂けると幸いです。 F2FS とは F2FS(Flash-Friendly File System) は Linux カーネル 3.8 でマージされた、Samsung が中心となって開発した、主にSSDに特化したファイルシステムです。 生のフラッシュメモリ 特化のファイルシステムは、既存のものが幾つか存在するのですが、F2FS はそれらとはまた違った構
このエントリーは、 Doc-ja Advent Calendar 2013 の 17日目の記事として書いています。 前日の担当者は、@okano_t さんです。 どうもこんにちは、 @syu_cream です。 主に、最近やっている Apache Traffic Server のドキュメント翻訳についてつらつらと書いてゆきます。 翻訳作業に着手して3ヶ月程度しか経過しておらず、まだまだ初心者の域を脱せていないと思うのですが、何か参考になることがあれば幸いです。 Apache Traffic Server is 何 Apache Traffic Server (以下、ATS)は、オープンソースの高性能 HTTP キャッシュプロキシサーバです。 元々は Yahoo!(米社) が自社で使用していたキャッシュサーバがOSS化されたもので、現在は Apache の Top level project
次のページ
このページを最初にブックマークしてみませんか?
『ブログ・ア・ラ・クレーム』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く