株式会社ZOZO 技術本部 本部長 兼 VPoEの @sonots です。この記事は「ZOZO Advent Calendar 2022」のカレンダー1の最終回（25日目）です。 振り返ると2022年は、昨年度の記事でも最後に「会社の統合、そして BizDevOps へ」と掲げているようにビジネス部門と開発部門が融合しやすい下地となる組織を作るべく邁進した1年だったように感じます。私個人としても、2022年3月に執行役員(前ZOZOテクノロジーズ社長)の久保田が退任し、VPoEとしてエンジニア部門統括の役割を引き継いだ大きな変化のあった1年でした。 この記事では、ZOZOで私と組織がこの一年、組織面で取り組んできたものをいくつか取り上げたいと思います。プロダクト面の進歩については「ZOZO ファッションテックハイライト 2022」の記事にまとまっていますので、そちらも合わせてご覧ください。

株式会社ZOZO 技術本部 本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー1の最終回（25日目）です。 2021年度、ZOZOにとっても、私にとっても大きな変化が2つありました。1つ目が2021年3月に前CTOの今村が退任し、私が全社技術戦略を策定する役割とZOZOTOWNリプレイスプロジェクト責任者を引き継いだこと、2つ目が2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、私も含む開発部門がZOZOに併合されたことです。 この記事ではその変化の中で私と組織がこの一年取り組んできたものをいくつか取り上げたいと思います。 全社技術戦略策定 2021年4月にCTO的な役割を引き継いで、個人的に一番変わったのは経営陣（当時はZOZOテクノロジーズ）との対話が増えたことだと思います。私の考えているCTOの役割と、経営陣の

とある python ライブラリが mmap(2) を使ってファイルを MAP_SHARED | MAP_POPULATE flags 付きでメモリに読み込んでいたので、その時 Linux メモリ管理系ツールではどういう挙動になるかチラ裏。 mmap お試しコード #include <fcntl.h> #include <stdlib.h> #include <sys/mman.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> int main() { int fd = open("abc.txt", O_RDONLY, (int)0400); off_t size = lseek(fd, 0, SEEK_END); printf("start\n"); char* addr = mmap(NULL, size,

この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad

k8s で deployment resource に変更を加えずに pod を立ち上げ直したいことは稀によくある。 例えば secret に変更を加えた場合それだけでは pod に変更が反映されないので rolling update させたくなる。 4年ぐらい前から戦っていたらしいがどうやら決着がついて v1.15 から kubectl にそのための機能である kubectl rollout restart が入るようだ > https://github.com/kubernetes/kubernetes/issues/13488

embulk-filter-calcite を使うと任意の SQL を書いてフィルタリングできて圧倒的に便利そうなので、拙作の embulk-filter-row および embulk-filter-column はお役御免にできるかと思って、速度比較をしてみました。 EDIT: (2017/05/19) embulk-filter-calcite 0.1.3 で高速化されたので再計測しました tl; dr embulk-filter-row との比較 Plugin Operator Time took records/s

embulk-output-bigquery の Partitioned Table 対応で調べてたので、その時に調べたものを雑にまとめておく。APIを直接叩いて実装しているので、bq コマンドでの使い方については調べていない。 EDIT: 現在は DATE もしくは TIMESTAMP カラムを指定した partitioning が可能ですが、本ドキュメント記載時にはまだ BigQuery がサポートしていなかったため、その記述が抜けています。 TL; DR 基本的に tableId に partition decorator ($YYYYMMDD) を指定して操作する DAYパーティションしか(今のところ)切れない。 特定パーティションのデータを置き換えたい場合は、パーティションを指定して、writeDisposition: 'WRITE_TRUNCATE'として load (または

Embulk のプラグインを作るにあたって、pure java と jruby でどれぐらい速度差が出るのか気になったので、それぞれ同じ動作をする簡単なプラグインを作って速度比較してみた。 java版 https://github.com/sonots/embulk-filter-java_pass ruby版 https://github.com/sonots/embulk-filter-ruby_pass このプラグインは、入力データをそのまま通すだけの filter プラグインで、ruby 実装だととても単純で、ただ入力を page_builder に add するだけになっている。 def add(page) page.each do |record| @page_builder.add(record) end end Java 版だと型があるので、Visitor を使ってもう少し