本記事では Ubie における最近の「開発生産性」というテーマで向き合っている事柄と実際のアクションについて紹介します。まだまだ発展途上ではあるのですが、何かの参考になれば嬉しいです。 背景「開発生産性」とは一見シンプルな概念に見えますが、世のテック企業、取り組んでいる人々のアクティビティを見ていると複雑で深いものにも感じます。例えば SpeakerDeck で「開発生産性」と検索することで多様な情報発信を見ることができます。有名な書籍として「 Lean と DevOps の科学」も、初学者が内容を頭に叩き込むのも難しいのではないでしょうか。これらの先行者の知見は素晴らしいものの...

Ubie における、小さく泥臭くはじめる開発生産性改善

結果Django のプロジェクトのテスト実行時間が、 GitHub Actions 上で 10min 超えになっていてつらみが出てきていた。のを、 manage.py test の --parallel オプションを活用することで実行時間を約半分に短縮できた。やったことDjango のプロジェクトでおそらくよくお世話になるだろう manage.py test には --parallel オプションがある。読んで字の如くであるが、このオプションを渡すだけで実行環境のコア数分並列実行をしてくれて便利。docs.djangoproject.comDjango のテストにおいてはデータベースにべったり依存したテストコードを書くことも多いと思うが、このオプションを渡すと起動時にワーカ分のテストデータベースを自動でいい感じに作ってくれるので、 並列実行におけるデータベース周りへのケアをあまり気にしなくて良くなる。...Creating test database for alias 'default'...Cloning test database for alias 'default'...Cloning test database for alias 'default'...Cloning test database for alias 'default'...Cloning test database for alias 'default'......自前で並列実行されることを想定されていない共用されると破綻するリソースがあるときは別途対策を入れる。自分が今回扱ったプロジェクトにおいては、「一時ディレクトリ」「Elasticsearch のインデックス」があった。この例においてはとりあえず共用リソース名の末尾に f"-{os.getpid()}" を付与してワーカ毎に異なる名前付けを行うことで回避するようにした。その他、 --parallel オプションを使用する上で tblib などパッケージをインストールすることを求められるケースがある。これらの工夫で、冒頭のように一定（自分の事例では 2 倍）高速になるなら儲け物ではないだろうか。

Django のプロジェクトのテストを並列実行してとりあえず2倍高速にした

はじめにこんにちは、 syucream です。 Ubie でソフトウェアエンジニアをやっています。ここでは表題の通り、筆者が関わっている Ubie の toC サービス開発の現場において、共用の QA 環境の利用状況をサクッと可視化したエピソードについて触れます。 課題Ubie の toC サービス開発の現場では、現在ソフトウェアエンジニアや QAE が動作確認をする時に共用の QA 環境を用いています。この運用は今までは十分に回っており、共用 QA 環境を用いた動作確認を行う前提でデプロイパイプラインやツールは最適化されてきました。しかしサービスの成長に合わせて開発に...

共用のQA環境の利用状況を Notion でノーコードで可視化する

本稿は Ubie Engineering Advent Calendar 2023 の 9 日目の記事です。https://adventar.org/calendars/9416 はじめにユビーでソフトウェアエンジニアをやっている syu_cream です。最近は社内で Enabling SRE っぽい動きやデータの信頼性に向き合っています。さて、みなさんは Sentry やそれに類するエラートラッキングツールを使っていますか？使っている場合、「有効に」使えているでしょうか？有効に使う工夫をしない限り、エラーが山積するのが可視化されるだけの混沌とした状況になることもあるかと思い...

Sentry と上手く付き合ってエラー監視を改善しよう

前回の記事で軽く触れていますが、現職 Ubie では症状検索エンジン「ユビー」の、リアーキテクチャを計画しています。さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。syucream.hatenablog.jp本記事では特にこの BFF 部分に言及しますが、リアーキテクチャの方針としてモジュラーモノリスへの移行を検討しており、実現に向けた検証が今月から始まっています。この取り組みが功を奏せば、前述の記事で言及した信頼性向上のためのアクションが取りやすくなるのはもちろんながら、プロダクトの開発生産性も向上することができるでしょう。合わせて考えるべき組織の話モジュラーモノリスとして引き合いに出されるのはやはりマイクロサービスアーキテクチャでしょう。マイクロサービスアーキテクチャでは典型的にはドメイン毎に分割されたサービスを持ち、サービス毎に異なるチームで開発・デプロイ・運用を行えます。ここでよく、マイクロサービスをどう切るかがが問題となり、コンウェイの法則に従いマイクロサービスに関わる組織をどう設計するかへ波及します。アーキテクチャとしてはよりシンプルで開発・ネットワークコストの少ないモジュラーモノリスでも、モジュールをどう切るかの問題は発生して、ひいては組織をどうすべきかの問題から逃げられません。組織に関する課題を考える上で、 Ubie においてはホラクラシーの導入などの効果により各メンバーが組織に対して強い関心を払っているのが効いてくると感じています。誰かが組織をいい感じに整えてくれるのを待つ（あるいは自分がいい感じにして整えたものを皆に下ろす）のではなく、自発的に組織課題に向き合うメンバーばかりが揃っています。それゆえモジュラーモノリスへのリアーキテクチャとそれに伴う組織への影響も、独りよがりなものにならず意見を反映させた形に持っていきやすいです。note.com一方で Ubie ならではの難しさもあると予感しています。Ubie のプロダクト開発組織ではチームトポロジーの導入が進んでおり、実際に症状検索エンジン「ユビー」を取り巻く組織構造はチームトポロジーの考え方を反映したものになっています。（ちなみにチームトポロジー導入前は、組織構造が大きく変わりプロダクトに及ぼす影響が甚大で、たとえばある機能に関心を払っていたチームが解散して誰もオーナーシップを持っていない状態になるなどの問題も起こっていました）note.comチームトポロジーの導入により明確に長生きすべきストリームアラインドチームが可視化されました。一方で Ubie のプロダクトはまだまだ発展途上にあり、プロダクト開発も激しさを増していきます。これを支える組織構造も引き続き、安定した箇所はありつつも変化が激しい箇所も存在し続け、チーム間のコミュニケーションも刻一刻と変わっていきます。組織を意識しながらリアーキテクチャを進めるコンウェイの法則によると、組織のコミュニケーション構造はシステムの設計に影響を及ぼします。チームトポロジーに従って安定を見せた箇所はありますが以前としてコミュニケーション構造は変わりやすく、リアーキテクチャではこれを念頭に置いた上で行えると良いと考えます。（まあこの辺の変わりやすい性質を考慮してモジュラーモノリスという選択肢を選んでいる側面もあり、変化に合わせて柔軟にあるべきアーキテクチャを更新するのはありそうですが）冒頭で述べた通りリアーキテクチャではプロダクトの開発生産性を改善したく、実際にプロダクト開発に携わるチームに価値を届けなければなりません。やっていくしかない！最後に、アーキテクチャと組織の両面を意識しながらプロダクト開発を邁進できる仲間を圧倒的に募集中ですので、何卒何卒！！！herp.careers

組織を考慮してアーキテクチャとシステム運用を改善する

こんにちは、syucream です。最近は業務で、症状検索エンジン「ユビー」 のプロダクト開発に携わっています。お陰様で症状検索エンジン「ユビー」はユーザ数も伸びて事業的にも重要なプロダクトとなってきています。プロダクトの成長に伴い、関わるチーム・エンジニアも増えて活発に機能開発がされています。一方で現在のスケールが見えてきたフェーズにおいて、今まで多少雰囲気でシステム運用してきたことの反動も起こっています。本記事ではシステム運用の観点で直近やってきたことやこれから取り組もうとしていることについて記述します。職人芸での運用、カオスなエラー捕捉体制、低いオブザーバビリティ今年初め頃はまだまだ属人性の高いシステム運用を行っていました。何かトラブルが発生した場合に、感度が高いエンジニアが勘や職人芸で対応しているシーンが多々ありました。システム運用はやや職人芸が輝く性質があるとは思われますが、属人的であるゆえプロダクトがスケールし始めていることを考えるとこのバス係数が低い体制は不健全です。また感度が高い特定のエンジニアが当事者意識を発揮しすぎてあらゆることをすることで、そのメンバーの燃え尽きや他メンバーの（システム運用における）当事者意識を育むチャンスの毀損など、長期的に見て様々なマイナスの影響もあると考えます。さて、以下に症状検索エンジン「ユビー」を支えるシステムの概略図を示します。（ここでは雰囲気が掴める程度まで簡単にしていますが）この図において FE・BFF・core BE は機能を継ぎ足し開発されていき肥大化してきています。加えてこれらのうち特に FE・BFF は複数のチームが関心を持っており活発に開発されてもいます。その裏側はややマイクロサービスアーキテクチャに倣ったような思想のもとドメインごとに基盤系サービスが分離された状態で配置されています。このアーキテクチャがベストかと言うと全くそうとは考えておらずリアーキテクチャプロジェクトが進行してはいるのですが、システム運用を考えると現状にも十分に目を向けなければなりません。アーキテクチャ概略システム運用体制は基本的な下地は整っているのですが、細部は詰まりきっていない状態でした。例えば、症状検索エンジン「ユビー」を支えるサービス群では Sentry でエラーを捕捉可能にしているのですが、捕捉はされるものの放置されるエラーが多く混沌としているのも問題でした。とりわけ FE はエラー量も多く愚直にトリアージするのは不可能な状態です。またオブザーバビリティが低く、どこで何の問題が起こっているかを迅速に把握するのが困難になっていました。一歩進んだシステム運用体制へプロダクトの成長に合わせて、システム運用も完璧とは言わずとも現状より一歩先に進みたいものです。そのためにまず目指したのが属人性の低減です。従来、属人的な職人芸で特に支えられてきたのが Sentry で捕捉していたエラーです。しかしカオスな状態でそのまま活用するのは困難です。これに対して以下の軸で整理を行いました特に有効活用できそうな BFF のエラー整理新規エラーに限定した通知エラー数の監視まず BFF のエラー整理について。前述の通り比較的活発に開発が行われているのは FE と BFF です。この中で FE はユーザの利用環境に依存してバリエーションが非常に豊かなエラーが発生する一方、 BFF の方はバリエーションは定まっています。これに着目して、まず BFF のエラーをトリアージして特に立ち向かうべきエラーを明らかにしていきました。この時のトリアージ方法としては以下の記事を参考にしました。zenn.dev次に新規エラーの通知です。 Sentry のアラート機能では、 Sentry 上で初出と判定されたエラーかどうかを条件にできます。これを用いて「初出のエラーのみ Slack に通知する」ことを実現しました。例えば何らかのリリースを行った直後に Slack に通知が来るようになったのならリリース内容を見直すといった活用が可能になります。Sentry の初出かどうかの判定はエラーが既存のものと同じグループに属するかの判定で行われ、これが期待に反する場合もあります。そのような場合には Issue Grouping の記述を参考に Fingerprint Rules を追記するなどの対応を行います。docs.sentry.ioまた、 Sentry のアラート機能ではエラー数が閾値を超えた時に通知することができるのでこれも合わせてセットしています。前述の新規エラー通知では把握しきれない、既出のエラーが大量発生しているようなケースもこれで拾えます。これらにより、 Sentry で捕捉しているエラーがカオスな状態でトリアージがしきれていない状態でも、一定はその中から価値ある洞察を得られています。また、基礎的なところからですがオブザーバビリティを高める活動にも着手しています。 Ubie のシステムのインフラは GCP に乗っかっていることを加味して、親和性の高い Cloud Trace を活用する、あるいは近しいところで Sentry の Profiling 機能を使い始めています。cloud.google.comdocs.sentry.ioアーキテクチャがまだ複雑過ぎると言うほどではないにせよ、人目でぱっと把握できるレベルは通り過ぎはじめています。その中で、どの処理がどこで遅くなっているかなど状況を把握できるデータが増えることの重要性は増してきています。この基礎的なオブザーバビリティ改善活動によって、例えば N+1 を解決してレイテンシを安定させた事例などもでてきています。レイテンシSLIが改善している事例ここまででシステム運用を簡単にする最低限の下地は改善してきているものの、これを一部メンバーで回している限りは属人性課題は改善していきません。これへの対処はまだ草の根的に模索中なのですが、アラートが届くチャンネルに関心を持ってくれそうなメンバーを広く巻き込む各メンバーが担当するシステムに当事者意識を持てるようなアーキテクチャ・システム・ガバナンス上の工夫をするを試しているところです。これも模索中ではありますが、粗々でも今あるツールを有効活用して異常時に多人数でコトに当たりインシデントハンドリングを以前より迅速に行えています。アラートを活用するメンバーたちの図1アラートを活用するメンバーたちの図2(この事例では調査の結果大きな影響は無く安心できた)これから目指したいところということで、プロダクトの成長に寄り添いシステム運用も改善する活動を紹介しました。もちろん現状が理想の形ではなく不足は多々ありますし、プロダクトがさらに成長することで要求も高まります。それにどう組織として立ち向かうかは引き続き考える必要があります。 Ubie のプロダクト開発組織においてはちょうど数ヶ月前に名前を「Ubie Discovery」から「Ubie Product Platform」に変更してより長期に渡るプロダクト価値最大化を目指すようになりました。このような組織レベルでのマインドの変化にも合わせてシステム運用の登り方もアップデートしていきたいものです。www.notion.so個人的には、さらなるオブザーバビリティや長期的にシステム運用に向きあるガバナンス整理、妥当な SLO の策定と運用、持続可能なトイル対処体制などやれることはまだまだあると感じています。さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。最後に、 Ubie ではシステム運用にも知見が豊富なソフトウェアエンジニアを募集しております！プロダクトの成長に伴いやることは枚挙に暇がありません。ぜひ一緒にやっていきませんか！少しでもご興味があれば、まずはカジュアル面談からでも、何卒！！recruit.ubie.liferecruit.ubie.liferecruit.ubie.life

症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動

以下のように紹介していた、 Ubie のエンジニアとラフに話せる Slack ワークスペースを運営していたのですが、このたびクローズしました。ご参加頂いたみなさま、ありがとうございました。ユビーに興味があるエンジニアの人たちとユビーの中の人でもっとラフに非同期で話せる場所が欲しいな......と思ったので、このたびそれ専用の Slack ワークスペースを作ってみました！🥳ご興味がある方、以下フォームより参加表明を！何卒何卒〜〜！！✨✨✨https://t.co/QHChQPIuLK— しゅー　くりーむ (@syu_cream) 2021年12月16日  なぜやっていたのかエンジニア採用の促進プレゼンスの向上(あわよくば) 技術交流によるナレッジシェアを目的としていました。特に採用のための施策としての色が強く、いわゆるカジュアル面談よりさらにカジュアルに交流できるコミュニケーションパスを用意したかった次第です。カジュアル面談は会社とその雰囲気を知るのに有効ですが、同期コミュニケーションの日程調整をしたり心理的ハードルが高く感じられる場合もあると踏んで、よりラフに非同期コミュニケーションを可能にしたかったのでした。なぜやめるのか運営がうまくいかなかった為です。何か重大な問題が発生した訳ではないのですが、ただただコミュニティ運営が疎かになりコミュニケーションがうまく発生しなかったのでした。コミュニティ運営はそれなりの熱意と時間を、長期的に継続して注ぎ込まないとワークしないと思われます。しかし現実、業務でこれを行うと会社の状況や業務で抱えるタスクの都合でリソースを回しきれないこともあり、十分な活動ができませんでした。またこのコミュニティの運用体制とそこから得たい成果を明瞭にし、改善を回すのもやるべきだったと反省しています。おわりにというわけで、ワークスペースを閉じることにしました。着眼点は悪くはないと考えているのですが、打ち手とその全体設計は改善の余地があったかと考えております。またどこか別の場所でおもしろコミュニケーションパスが爆誕することがあれば、より活発に皆様と交流できると嬉しいです。ちなみに Ubie では引き続き絶賛エンジニア募集中です！ Slack コミュニティはなくなってしまいますが、ユートラのカジュアル面談募集や情報発信、もしご興味がおありでしたらご覧いただけると嬉しいです！youtrust.jpblog.ubie.tech

自社のエンジニアとラフに話せるSlackワークスペースをクローズした

こんにちは、 syu_cream です。普段は Ubie でプロダクト開発エンジニアをやっています。本日は業務で構築した社内向け gem の継続的なリリースを行う仕組みを紹介します。 GitHub Actions & Packages の組み合わせは問題にハマると原因究明が難しいことがあり、また意外にも世の中に情報が乏しいように思えます。この情報がひとつの参考になればと思います。はじめにUbie では、以下記事で紹介しているように新規に開発するサービスを Go か Node.js で、通信プロトコルを GraphQL か gRPC で実装する方針を進めています。zenn.dev最近、僕の所属チームでも新規サービスを追加したい状況に直面し、上記記事の基準を加味して NestJS による gRPC サーバを実装することにしました。現在 Ubie では Protocol Buffers による gRPC のサービスやメッセージの定義と付随するコード生成等のエコシステムは中央集権的なリポジトリが担っています。ここで NestJS で使いやすいコードは既に GitHub Packages で社内向け npm パッケージとして利用可能になっていました。しかし今回開発する gRPC サーバに対する想定クライアントとして昔から存在する Ruby on Rails 実装の REST API サーバがあり、他言語に従い Ruby 向けのコード生成も行いたくなりました。このような経緯があり、本記事タイトルの「GItHub Packages を使って社内向け gem をリリースする」のを、属人性を排除しつつ簡素な構成で行うため GitHub Actions で完結させたい次第になりました。GitHub Actions から社内向け gem をリリースする今回まず Protocol Buffers, gRPC のコード生成をする必要があったのですが、ここは Buf を使いあまりハマることなく実現することができました。以下ページを参考に、 Ruby 向けの gRPC/Protocol Buffers プラグインを導入して buf generate するだけです（まだ複雑なことをしていないが故に問題にハマってないだけの可能性は否めないですが）buf.build本題の gem のリリースですが、基本的には以下ドキュメントに従うことになります。docs.github.comまず gemspec を用意します。（一部置換を含みつつ抜粋）今回 GitHub のリリースタグからバージョンコントロールしたいので、環境変数から注入可能にしています。また allowed_push_host メタデータは gem push する先にを指定しておきます。 lib/**/*.rb には buf generate で生成されたコードが配置されている想定です。Gem::Specification.new do |spec|  spec.name          = "..."  spec.version       = ENV["PACKAGE_VERSION"]  spec.authors       = ["..."]  spec.summary       = ""  spec.required_ruby_version = Gem::Requirement.new(">= 2.7.0")  spec.files         = Dir["Gemfile", "lib/**/*.rb"]  spec.require_paths = ["lib"]  spec.metadata["allowed_push_host"] = "https://rubygems.pkg.github.com/<namespace>"  spec.add_runtime_dependency "grpc", "~> 1.x"end次に GitHub Actions のワークフローを組みます。実際に作成したものは以下のようなものになります。（一部置換を含みつつ抜粋）gem push をするにあたり Actions に Packages に書き込みを行う権限が必要です。リポジトリの設定 ( Settings > Actions > General > Workflow permissions ) で書き込み権限が付与されているかワークフローの設定で permissions.packages: write が必要になるはずです。 また公式ドキュメントを参考に gem push する際の認証情報を渡します。  ruby:    runs-on: ubuntu-latest    steps:      - name: Checkout        uses: actions/checkout@v3      - name: Setup Buf        uses: bufbuild/buf-setup-action@v1        with:          github_token: ${{ github.token }}      - name: Setup Ruby        uses: ruby/setup-ruby@v1        with:          ruby-version: '2.7'          bundler-cache: true      - name: Generate code        run: |          buf generate ..      - name: "Define PACKAGE_VERSION"        run: |          echo "PACKAGE_VERSION=${{ github.event.release.tag_name }}" >> $GITHUB_ENV      - name: Build        run: |          gem build <gem name>.gemspec      - name: Publish artifact        run: |          echo ":github: Bearer ${GITHUB_TOKEN}" >> ~/.gem/credentials          chmod 600 ~/.gem/credentials          gem push --key github --host https://rubygems.pkg.github.com/<namespace> <gem name>-${{env.PACKAGE_VERSION}}.gem        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}このワークフローではそのために明示的に PAT 払い出しをする必要がなく、 GITHUB_TOKEN で簡潔に構成できます。それゆえ GITHUB_TOKEN 起因の認証エラーにハマることがあるかもしれませんが、トークンの渡し方や付与されている権限を確認しながらトラブルシュートしていくことが求められます。社内向け gem を利用するgem がリリースされたら、利用する側も作り込んで行きます。これも基本的に公式ドキュメントにあるように、 Gemfile にリリースされた gem への依存を書いてsource "https://rubygems.pkg.github.com/<namespace>" do  gem "<gem name>", "<version>"endbundle config で source にアクセスする時の認証情報をセットしておきます。これで bundle install でリリースされた社内向け gem をインストールできます。$ bundle config https://rubygems.pkg.github.com/<namespace> <GitHub のユーザ名>:<GitHub の PAT>このやり方は GitHub Actions 上で行いたい時障壁になるかもしれません。その場合は環境変数を介して渡すことも可能なようです。    - uses: ruby/setup-ruby@v1      with:        ruby-version: ${{ env.RUBY_VERSION }}        bundler-cache: true      env:        BUNDLE_RUBYGEMS__PKG__GITHUB__COM: ${{ secrets.GITHUB_TOKEN }}おわりにというわけで社内向け gem を GitHub Actions & Packages でリリース・利用する事例について紹介しました。 GitHub Actions、 Packages は上手く使えれば簡潔で使いやすい開発基盤を構築できると思うのですが、問題にハマるとストレスフルな状況になりがちかなと思います。本記事がひとつの事例としてお役に立てば幸いです。

GitHub Actions と GitHub Packages を使って、継続的に社内向け gem をリリースする

ライフワークバランスが重視される昨今、そのバランスを保つのって簡単なんでしょうか？他人が多くを語らない詳細は、見えないからこそ想像を掻き立ててしまって自分には手が届かない理想的な生活を描いてしまいそうですよね。でも実際は全然そんなことはないはず。本記事では、僕が直近 2023 年 1 月から育休復帰して 3 ヶ月を振り返って、仕事と育児のバランスの実情や難しい点を綴ってみます。育児にコミットしながら仕事に復帰すること自分の家庭では、自分と妻の実家の手助けはほとんど得られず自分たちで育児を成立させる必要があります。また主に家計を支えるのが自分となる都合、妻になるべく育児に集中して欲しい期待感もでてきます。しかし妻が産後思いのほか体調が優れないことが多く、育児をワンオペで回し続けるのは負担がかかりすぎます。妻にばかり負担を掛けぬよう、なるだけ自分も育児に参加して負荷分散する必要があります。なるべく仕事の出力を維持しながら。幸いなことに現在の職場 Ubie（ユビー）株式会社 では リモートワーク が可能です。出社する機会はあるのですが、あまり無理なくリモートワーク主体で働くこともできます。ここ 3 ヶ月はほぼリモートワークで、仕事をしながらも子供がミルクを欲しがったり不機嫌になる状況でスポット的に仕事を中断して育児の時間を設けるようにしました。この柔軟な勤務状況は、 裁量労働制 で働けることも手伝っている結果です。一部仕事を抜けてしまった分を他の時間で補填しやすいのです。また Ubie では自分と同じく 子供を育てながら仕事しているメンバーも数多く 、仕事しながらも育児も大切にすることへの抵抗感も少ないことも助かりました。一方リモートワーク主体で仕事をしていると、オフラインコミュニケーションの機会が少なくなります。Team Geek という書籍に「フェイスツーフェイスの帯域を過小評価してはいけない」という表現が出てきますが、まさに制限されたコミュニケーションパスで仕事していたような心地ではありました。その制限により、オフラインで誰かと会って話せていれば獲得できていた情報の欠如などを引き起こしていたかもしれません。仕事と育児以外のもの育休から仕事復帰する以上、仕事で成果を上げたいものです。しかし育児にもコミットしたい。この 2 要素を天秤にかけることはよくあると思うのですが、当然人生には他の要素も絡んできます。自分の反省として、仕事と育児以外のものをだいぶ劣後させてしまったことがあります。優先度的には、 仕事 >> 育児 >>>>> 妻のこと >>>> 自分のこと みたいな構図になってしまい、妻との関係性の悪化や自分自身の不調を招いてしまいました（そんなに致命的ではないですが）短期的には仕方ない部分もありつつも、妻と自分、子のみならず親のコンディションにも気を配るべきでした。お金子育てにお金がかかるのは本当にそうで、まず赤ちゃんの為のグッズに少なくない金額がかかります。それで済んでいればよいのですが、僕の家庭ではベビーシッターやヘルパーさんを頼んで自分と妻の負荷軽減と妻の通院を柔軟にできるようにした都合、 1-3 月にそれぞれ 5 万円以上かかるという家計に苦しい状況にもなりました。これについては正直しょうがないと思っています。大変かつ他の手段も限られている状況で、お金で解決できる領域があり支払い能力があるならお金で解決してしまう、は一定正解のはず。幸いなことに 0 歳児で保育園に入れたので解消もされていく、はず。それでも希望はある大変なことを列挙するとうんざりしてしまいますが、やはり子供は可愛く癒されるものです。（自意識過剰でなければ、子供が僕に特に懐いている気がする！！）また、子供の圧倒的成長や保育園入園などの節目を一緒に体験していると、人生二週目をやっているような心地というか、刺激が数多くあるように感じられます。仕事とプライベートの両立はやはり難しく上手に行える気がいまだにしないのですが、現実な落とし所は探っていきたいところです。

育休復帰後 3 ヶ月を振り返って、仕事とプライベートの両立ハードパーツ

引き続き子育てエントリです。前回はこちら。syucream.hatenablog.jp3.5 ヶ月この頃から子供が寝返りをするようになりました。ちょうど 3.5 ヶ月にわずかに満たない頃から、ぎこちないものの寝返り可能になり、 3.5 ヶ月を過ぎたあたりからスムーズに寝返りし始めました。典型的な赤ちゃんの発達においては 4 ヶ月頃から寝返りをする子が多いようで、それと比較するとやや早いタイミングでの寝返り開始となります。仕事面では、この頃職場復帰して 1 ヶ月が経過しました。仕事と育児を両方とも上手くこなすのは、体力的にはギリギリ捌けると感じます。自分の今の勤務体制がガチガチに決まった時間に働かなければならないものでもないことを生かし、概ね日中〜夕方くらいまで仕事してその後は家事育児のために離脱。やり残した仕事があれば寝る前に少しおかわりするという日々を送っています。これにより仕事と育児の両方のバランスを取ることはできそうです。注意しないと疲労を延々と引きずってしまいそうですが。ちなみに私的な時間、たとえば子供が生まれる前にやっていたゲームや読書などする時間までは正直割けず...犠牲になったのだ。4 ヶ月3.5 ヶ月頃から開始した寝返りは更なる安定をみせます。ただし所詮は赤子の限られた体力であり、うつぶせになった状態でしばらく経過すると疲れて泣き始めてしまいます。泣き始めるものだから仰向けに戻すと、自分で再び寝返りをして、さらに疲れて泣き始める...無限ループかな？寝返り以外だと、徐々に手を器用に使っておもちゃで遊ぶようにもなり始めました。仕事面では大きな変化はないですが、やはり出力を上げたい時に悩ましくはなってしまいます。夕方〜夜は育児のために継続的に時間を割いているものの、その時間も仕事に避ければより進捗するのでは、と考えないかというと嘘になります。無理して作業時間を捻出しても体力や家庭の平和を損ないそうですし、ライフワークバランスは難しい。ここからライフワークバランスはギリギリ問題にはなっていないものの一定の整理をつけないといけない課題になってきているようにも感じます。また薄い望みですが子供が保育園に通えるかどうかがそろそろ分かり、通える場合はまた日々の過ごし方、生活リズム、妻との育児上の役割分担など考えることが多々出てきそうです。

ソフトウェアエンジニア子育てログ (3 ヶ月 ~ 4 ヶ月)

前回のブログエントリで計画した通り、しばらく子育てが加わった日々を綴ります。2 ヶ月 ~ 3 ヶ月編。syucream.hatenablog.jp2.5 ヶ月引き続き子供は夜中にまとまってくれています。恐らくこの月齢では一般的ではなさそうですが、深夜にミルクを欲しがって起きることなく連続で 6 ~ 10 時間ほど寝るのが定着してきました。またクーイングから始まった原始的なコミュニケーションは、いろいろな抑揚を加えたり、笑い声を含めて笑うなど若干のバリエーションの増加を見せてきました。この頃がちょうど 2022 年末から 2023 年始頃でした。しかし当たり前というべきか、子育てに忙殺され年末年始感はまるで無く、知らぬ間に年を越していたような感覚になっています。3 ヶ月この頃になると、子供の首がだいぶすわってきて縦抱き抱っこも安定して行えるようになってきました。さて、年を越して予定通り育休を明けて職場復帰しました。自分も全く育児にコミットしない訳にはいかず、手が開いた時にアドホックで対応に入ったり、 18 時以降は授乳や子供のお風呂などに時間を割くなどします。仕事に避ける時間や集中力は、やはり子育てを開始する以前より落ちたように感じます。また当然ながら育休で二人体制で育児にフォーカスしていた状態から自分が育児に避けるリソースが減ることで家庭内での余裕は少し目減りします。（1 月の第 1 週が一部三が日で、第 2 週が祝日で平日 5 連続しない配列になっていて幸運でした。）育児に避けるリソースが少なくなった分は、妻が努力してくれているのもそうですが、ベビーシッターや公的な補助を駆使して一部補填することも試し始めました。ここから家事・育児・仕事の両立をなんとか開始した状態です。現状なんとかなっているものの体調を崩すなど不足の事態が怖いものです。なんとか余剰リソースを生みたいものですが。。。

ソフトウェアエンジニア子育てログ (2 ヶ月 ~ 3 ヶ月)

先日、我が家に第一子が誕生しました。祝っていただいた方々、日頃お世話になっている方々、本当にありがとうございます。Hello, world. pic.twitter.com/Ug7O3amt8a— しゅー　くりーむ (@syu_cream) 2022年10月14日  さて、子育てが早速、世に聞く通り通りなかなか過酷に感じられているのですが、その日々を日記っぽく綴っていこうと思い立ちました。仕事と育児の両立について同様のテーマを扱ったブログエントリは多々あると思いますが、この少子化の世の中子育てに関する情報はなんぼあっても良いでしょう。子育ての苦労が喉元過ぎて熱さを忘れる前に記録することが後の自分にとっても参考情報になるとも考えられます。そんなわけで、定期的に子育てエントリを書いていこうと思います。誕生直前9月末までで概ね引き継ぎを行い、 10 月頃から 2022 年内まで育休に入ることにしました。育休取得の期間は正直確たる理由はなく、出産から少しの期間取得して年末復帰してもすぐ休みボケしそうだし業務の時間的な連続性がなく効率的でないように思えたため年内いっぱいお休み、としました。また育休取得に伴い、引き継ぎ等同僚に圧倒的に支えられたと感じます。圧倒的感謝。出産にかけては、深夜に破水が始まり急遽タクシーで乗りつけたり、予定よりお産が早く進んだこととコロナ禍において面会が厳しくなったことで出産の瞬間に立ち会えなかったり、それなりに慌しかったものの結果的には健康な子が生まれました。0ヶ月 ~ 1ヶ月出産・退院後から生後 1 ヶ月になるまでが、現状最も過酷でした。過酷である要因としてはお産直後で妻の体力が激減してる3時間ごとの授乳で夜に熟睡できない子供の泣き声をずっと浴びてるとストレスがマッハ子育てに慣れてなさすぎて様々な不都合があったなどなどです。ちなみに今回の育休中、以下のエントリも参考にしたこともあり、副業は続けていました。　zenn.devただ最初の 1 ヶ月は本業ほどではない稼働である副業もまとまった作業時間を確保するのに苦心しました。1 ヶ月 ~ 2 ヶ月1.5 ヶ月ほどが経過した頃、子供が夜にまとまって眠るという素晴らしいアップデートがあり、夜の睡眠に平和が訪れました。また、妻の体力が少し持ち直してきたことや、産後ケア施設利用で子育を休む日を作ること、全体的に子育てに少し慣れたことで余裕も感じられるようになってきました。加えて子供が社会的微笑やクーイングを行うようになり、拙いながらも子とのコミュニケーションが生まれ始めたのも嬉しいものでした。余裕が出始めたことによる副作用か、この頃から個人的に子育てに集中している日々にマンネリ感というべきか、飽きのようなものを抱き始めました。ほとんど家から出ず、急速に成長中とはいえ日ごとくらいの粒度では変化はそれほどない子供の様子を見続けるだけというのに刺激があまり感じられませんでした。この後ろ向きな変化に「飽き」などと名前づけてしまうと周囲から余計なツッコミをもらってしまいそうですが、しかし自分としては緩和策を用意した方が良さそうです。ここから2023 年になり育休も明け、仕事と子育をうまく両立させていく必要がでてきました。どうなってしまうのか？その様子は挫折しなければしばらくは隔週で残していければと思います。三日坊主で終わらなければいいけど。

ソフトウェアエンジニア子育てログ (0 ヶ月 ~ 2 ヶ月)

みなさんいかがお過ごしでしょうか。 @syu_cream です。わたしは半年ほど前にユビー株式会社へソフトウェアエンジニア(以下 SWE)として転職しています。転職前後のストーリーは以下のエントリにて紹介しています。syucream.hatenablog.jp本記事では入社から半年後にかけての展開について綴ろうと思います。ユビーの SWE についてまず自分が在籍する、ユビーの SWE というポジションについて触れておきます。昨今のテック企業では選考の間に技術面接を経てポジションにマッチする技術力を持っているかを評価するケースが多々あると思われますが、ユビーではこのような技術面接は行っていません。その代わりに、特定の技術スタックへの理解が深いかどうかなどは問わず、プロダクト開発に欠かせない素養があるかを確認するため面接を設けています。この面接の体系についてはより詳しくまとめた記事があります。note.comユビーの SWE として入社した後の話入社時点でのスキル技術力を評価されずに入社した後、実際に業務を回せるのか。どのような活躍ができるのか。もしかしたら疑問に思われる方もいるかもしれません。さて、わたしもユビーの選考を受けた時にこちらの面接を受けています。そして実際、ユビーでは多用される Kotlin や GraphQL 、 React などの知識があるかは問われることなく選考を終えております。以下がユビーで採用している主要な技術なのですが、 React や Kotlin は少し触れた程度、 TypeScript や GraphQL は触れたことすらない程度で、実務レベルの経験をしているとはお世辞には言えない状態でした。（ GCP については幸いながら 3 年以上の経験がありました）入社後半年間のプロダクト開発業務そのような、技術スタックのマッチ具合でいうと芳しくない状態からここ半年間で、以下のような開発業務に携わっています。ユビーAI受診相談 と関連サービス ユビーリンク医療データを管理するマイクロサービス ( 参考 )Cloud Spanner の利用検討全体的に、必要な技術は必要になったその都度細かく学習しつつ、あまり学習に時間をさきすぎず開発を進めています。 React、 TypeScript の知識があまりないまま 1. のユビーAI受診相談の開発に着手した際は正直かなりの苦戦を強いられましたが、物怖じせず突っ込んでみて必要に迫られた知識を習得するのは自分の性分とは合っているように感じています。また GCP の利用経験があることから適度にインフラ周りのタスクも並行して取り、やろうとしていることが何も分からない！という状態を回避しています。そうして都度キャッチアップを繰り返していると既知の領域も広がってゆき、入社後半年経過した現時点では、分からないことも多々ありつつも開発を回せるようにはなってきています。そんな訳でスキルのミスマッチは何とかカバーすることはできているのですが、他方でタスクの見積もり精度が甘くなったり消化が遅れるなど、スキル不足ゆえにバリューを発揮しきれずもどかしさを感じるシーンもあります。ただこの点は現在は苦しみがあるものの、キャッチアップを続けていくうちに時間が解決してくれる部分もあるかと考えています。プロダクト開発以外での貢献ユビーの SWE はプロダクト開発以外にも OKR 作成と議論、ホラクラシー組織開発、採用などやるべきことが多々あります。それぞれ少なくないリソースを注ぐことになり、リソースが分散することに辛さもありつつも多岐に渡る活動ができることには面白さを感じています。この中で特にわたしがコミットしているのは採用です。例えば、その一環で直近ですと以下のようなユビーに興味を持ってくれる人が集まれる Slack ワークスペースの用意などを行っています（もしご興味がおありの方いらっしゃれば、ぜひご参加ください！！！）ユビーに興味があるエンジニアの人たちとユビーの中の人でもっとラフに非同期で話せる場所が欲しいな......と思ったので、このたびそれ専用の Slack ワークスペースを作ってみました！🥳ご興味がある方、以下フォームより参加表明を！何卒何卒〜〜！！✨✨✨https://t.co/QHChQPIuLK— しゅー　くりーむ (@syu_cream) 2021年12月16日  会社の様子というのは社外からは観測しがたく、またカジュアル面談は”カジュアル”とうたいつつも実施までに時間的・心理的ハードルが高い課題があるのではという仮説を持っています。これに対して、社内メンバーが同時に多数参加できかつ気軽なテキストベースのコミュニケーションが可能な Slack ワークスペースを設けることで一定対策できるのではと考えた次第です。すぐの採用に繋がらなくとも会社のプレゼンス向上に期待することも期待できます。採用ひとつとっても奥深く、プロダクト開発以外にもコミットすることで面白い経験ができています。おわりに以上、わたしがユビーに入社するあたりから半年目までの簡単な振り返りでした。技術スキルのマッチ具合やスキル不足で転職をためらう人は多々いると思いますが、わたしのように後からキャッチアップして辻褄を合わせるというやり方もあります。できないことが多い時期はそれなりの苦しみを感じますが、アンラーンして新しい技術を吸収できる素養さえあればやがて乗り越えられるはずですし、できることが増えた状態で見渡す景色は美しいものです。特にわたしが所属するユビーではアンラーンしてやっていける素養を重視するので、その点で不安を感じる方がいればご一考いただけると嬉しいです！最後に、 Meety 上でカジュアル面談募集しております。本記事やユビーについて気になったことがございましたら、ぜひご応募ください！meety.netmeety.netもっと気軽にお話したいご希望ありましたら、記事中で紹介した Slack ワークスペースもぜひ！ユビーに興味があるエンジニアの人たちとユビーの中の人でもっとラフに非同期で話せる場所が欲しいな......と思ったので、このたびそれ専用の Slack ワークスペースを作ってみました！🥳ご興味がある方、以下フォームより参加表明を！何卒何卒〜〜！！✨✨✨https://t.co/QHChQPIuLK— しゅー　くりーむ (@syu_cream) 2021年12月16日

ユビーに転職して半年、慣れない技術スタックでも何とかやっていけている

はじめに今年も残り少ない日数となってきた今日この頃。みなさんにとって今年はどんな年になりましたか？ぼくの所属するユビー株式会社も今年も様々な飛躍と進化を遂げております。ubie.life特に多様なバックグラウンドを持つ優秀なメンバーが加入したことは目覚ましい点です。とりわけ「エンジニア」という枠 ( https://recruit.ubie.life/engineer 以下で定義されている JD ) で加入したメンバーは今年 20 人ほどいるようでした。とは言うもののさて、具体的にはどのようなメンバーがジョインしたのでしょうか。ユビーのメンバーは転職する際にいわゆる転職ブログエントリを書いているケースが多く、この場でいくつか抜粋して紹介させていただこうと思います！転職エントリを一部紹介！@itkq転職えんとりーです / Ubie 株式会社に入社していた https://t.co/anCRYSNhut— いたこ (@itkq) 2021年2月24日  まずは SRE の @itkq です。コロナ禍で長く続くリモートワークと事業への貢献を加味して転職への転換を振り返っています。@h13i32maruUbieという医療系ベンチャーに転職するので、ブログかいてみました。転職の意思決定（クックパッド → Ubie）https://t.co/LChrlFDghN— Ryo Maruyama (@h13i32maru) 2021年2月12日  次はソフトウェアエンジニアとして toB 向けサービス開発をしている @h13i32maru です。転職という意思決定をする上で、感情に流されず懸念要素を洗い出し整理していく良エントリを書いています。@empitsu88食べログからUbieに転職してそろそろ2ヶ月なので、いわゆる入社エントリを書きました。ソフトウェアエンジニアとしてUbieに入社しました #note https://t.co/vXyOFmqs2C— えんぴつ (@empitsu88) 2021年8月11日  お次もソフトウェアエンジニアの @empitsu88 です。働きやすさという観点も加えて転職を振り返ってます。@jagabassUbieに転職して1ヶ月が経ったので入社エントリを書きました！転職活動時の意思決定や入社後の感想を中心にお話ししています〜 https://t.co/2Zf2KLK5WP— じゃがじゃが (@jagabass) 2021年8月2日  @jagabass はデータアナリストとしてジョインしデータ分析スキルを武器に幅広く活躍しています。@syu_cream近況です。今後ともよろしくお願いいたします。https://t.co/8WpmGWqhe4— しゅー　くりーむ (@syu_cream) 2021年8月4日  筆者自身です。ソフトウェアエンジニアとして転職しています。コンフォートゾーンの脱出と自身のスキルセットの多様化などの思惑を踏まえ、ユビーへのジョインを決断しています。@dtaniwakiUbieに入社して1ヶ月経ったので、入社エントリーを書きました。#Ubie #ユビー #SRE #Kuberneteshttps://t.co/q5p9CHiNXY— Daisuke Taniwaki (@dtaniwaki) 2021年9月7日  SRE として @dtaniwaki ジョインして、持ち前の技術力の高さを生かしてインフラ整備やイベント登壇など多岐に渡る活躍をしています。@m_mizutani書きました。9月からはUbieという医療系のスタートアップで引き続きセキュリティエンジニアをやっていきます。各位何卒よろしくお願いいたします。転職します（Cookpad → Ubie） - ある研究者の手記 https://t.co/KyA6SA8EHL— mizutani (@m_mizutani) 2021年8月1日  @m_mizutani は比較的最近できた セキュリティエンジア ポジションでジョインしています。最近は一人アドベントカレンダーを回すなどしており...正気か！！？adventar.org@shikajiroZOZOテクノロジーズ/ZOZO研究所を退職しました。次は医療xAIスタートアップUbieに行ってきます。｜shikajiro @shikajiro #note https://t.co/jsRGXr2red— しかじろう (@shikajiro) 2021年8月5日  @shikajiro はソフトウェアエンジニアとして入社しており、現在 toB 向けサービスの開発に従事しています。「ML以外のエンジニアリング全部やる」をモットーに活躍してきたところからの転職、エモさ溢れるエントリを書かれています。@hokaccha近況です | クックパッドを退職して Ubie Discovery に転職しました - hokaccha memo https://t.co/N3KdNGIacH— hokaccha (@hokaccha) 2021年9月1日  @hokaccha もソフトウェアエンジニアとして入社しております。彼もまたエモさ溢れるエントリをしたためています。とりもどそう、青春。@okiyuki99本日12/1からUbieに入社しました。スタートアップらしく、崖の上から飛び降りながら飛行機を作る環境をEnjoyしていきたいと思います— OKIYUKI (@okiyuki99) 2021年11月30日  ブログエントリではないですが、データアナリストとして @okiyuki99 もジョインしています。早速多角的にデータ分析をしてプロダクトにバリバリ貢献しています。ohtaman本日から Ubie Discovery です！BrainPadのみなさん、12年間ありがとうございました！ #はてなブログ12年お世話になった BrainPad から Ubie へ行きます - 0-8 https://t.co/FpmJkO0Kyg— おおたまん (@ohtaman) 2021年11月30日  ohtaman は前職において CDTO （最高データ技術責任者）という立場におり、ユビーには機械学習エンジニアとしてジョインしています。 12 年間にわたる前職の振り返りとユビーでの展望、読み応えがあります。@takahi_i書きました！ /  Ubie Discovery に転職しました（人生初の入社エントリ）｜takahi_i @takahi_i #note https://t.co/BWBn79tc5s— Takahiko Ito (@takahi_i) 2021年9月17日  @takahi_i は機械学習や検索を得意とするエンジニアであり、「MLがサービスの根幹で使われている」ことなど専門性を活かせる職場であることをエントリで振り返っています。おわりに上記に挙げたのは一例で、他にも紹介しきれない魅力的なメンバーがおります。優秀なメンバーが揃うドリームチームが出来上がりつつあり、個人的には良いメンバーと一緒に働けるこの環境がある種の福利厚生にも思えてきています。が、ユビーの野望は果てしなくチャレンジしたい領域が多分にある一方まだまだ人が足りません。まだまだ手の届いていない課題が山ほどあります！このエントリをみているあなたの将来の選択肢にユビーを考えてみませんか？ユビーについてもっと知るには、以下のページをご覧頂けると幸いです。recruit.ubie.lifeMeety をやっているメンバーも多く、カジュアル面談もお気軽にご参加いただけます。meety.netまた、最近ユビー在籍エンジニアとラフに話せる専用 Slack ワークスペースを用意してみました。招待制になっておりフォームの入力が必要になってしまいますが、ぜひお気軽にご参加ください。カジュアル面談より更にカジュアルな非同期に話を聞く場として、あるいはユビーの雰囲気を感じ取ることを目的として、ご活用いただけると嬉しいです！ユビーに興味があるエンジニアの人たちとユビーの中の人でもっとラフに非同期で話せる場所が欲しいな......と思ったので、このたびそれ専用の Slack ワークスペースを作ってみました！🥳ご興味がある方、以下フォームより参加表明を！何卒何卒〜〜！！✨✨✨https://t.co/QHChQPIuLK— しゅー　くりーむ (@syu_cream) 2021年12月16日

2021年Ubie Discoveryエンジニア入社エントリまとめてみた

表題の通りで、 2021年7月より前職の株式会社メルペイ（メルカリ）を退職して Ubie に転職しました。というわけでいわゆる転職エントリです。TL;DRメルカリ・メルペイに 3 年 10 ヶ月在籍しましたスキルや経験の幅を持たせたい、サービス初期の雰囲気をまた味わいたくて転職Ubie に入社して SWE として働き出して一ヶ月経過しましたメルカリ・メルペイでやってたことメルカリには 2017 年 8 月に入社し、約半年間 SRE チームに所属していました。その後メルペイの立ち上げに合わせて異動して 2021 年 6 月末までデータエンジニアをやっていました。本当に数多くの同僚や関係者に恵まれておりました。お世話になった方々ありがとうございました。メルカリ・メルペイで体験したことは枚挙に暇がなく、約 4 年で体験したことなのかと疑うほどに濃密なものでした。プロ集団の SRE チームの一員として働き、刺激を受けたこと。メルペイの立ち上げ初期メンバーに加わり、大規模な新サービスのローンチに関われたこと。マザーズ上場。社員数の急拡大（自分が入社した頃より最終的に約 3 倍になった！）と多様なバックグランドを持つメンバーが揃い出したこと。大量のデータを取り扱うデータ基盤の構築にリソースを振り切れたこと。特にデータ基盤の構築は約 4 年の歳月の中で注力していた事であり、成果を Builerscon 2018 LT や ApacheCon NA 2019 で発表させて頂くにも至りました。 speakerdeck.com speakerdeck.comメルカリ・メルペイは先日発表があったメルカリShops や、メルコインも手がけており、現状に満足せずに Go Bold に挑戦し続る、刺激の強い環境です。about.mercari.com将来に向けた葛藤そんな良い環境を手放してまで転職する理由としては、ひとえに自分のキャリアと将来を考えた上で別の道を歩むのが良いと判断したためです。転職に至るまで以下のような葛藤を抱えていました。自分の年齢と人生を考慮して今もっと挑戦すべきと感じた自分の立場がコンフォートゾーンになってきたスタートアップの雰囲気をより感じたくなったそれぞれ分解してみます。自分の年齢と人生を考慮して今もっと挑戦すべきと感じた今年で自分は 33 歳であり、今後のライフイベントも考慮するとどこまで自由に挑戦できるか疑問が浮かびます。今このとき、体力や情熱があり多少人生の時間の使い方を自由にできる時により挑戦すべきではないかと感じていました。自分の立場がコンフォートゾーンになってきたありふれた話ですが、自分の立場がコンフォートゾーンになり、新しい刺激が少なく成長をあまり実感できなくなっていました。メルカリ・メルペイでは主にデータ基盤の開発と運用をやっていました。こうしたいわゆる社内プラットフォームやプロダクト基盤などと呼ばれるシステムの担当分野においては、特定の技術的な問題と挑戦にフォーカスしやすい反面、ビジネス上のドメイン知識の獲得や多様な技術の理解が得難いというデメリットがあると考えます。また基盤刷新や新技術の導入で新しい知識を獲得する機会はあるものの、徐々に強くてニューゲームになり刺激が無くなってくるようにも感じます。自分の直近の実例を取ると、 Apache Airflow や Apache Beam, Apache Spark, Apache Flink を活用したデータ収集基盤の構築や BigQuery による出たウェアハウス提供に従事してきました。他方、連携するマイクロサービスの知識はそれほど身に付かず、 Android, iOS アプリや Web のフロントエンドについては更に距離のある話題になっていました。前前職まで遡ると、自分のキャリアにおいてプラットフォーム的な役割に振った時間は 8 割ほどを占めています。この方向性を維持するにも別の道を模索するにも、より多様な経験を積んで能力や発想に幅を持たせるべきではないかと考えました。スタートアップの雰囲気をより感じたくなった自分がメルカリに入社した頃と比べて社員数は劇的に変化しました。組織は成熟して上場も果たし、仕事の仕方も自分の入社した頃と比較してこなれてきた印象がありました。それに際してどこか「昔はよかった」と感じてしまうシーンが増えてきました。（大抵は思い出を過剰に美化しているかもですが）考えるべきこと、やるべき仕事が多量にある急成長中のスタートアップでは刺激も多く学べることがあるはずです。自分には今、再びそのカオスだけど喜びが多い環境に身をおくべきなのではと葛藤しました。Ubie 入社前述のような葛藤をかれこれ半年ほど続けて、最終的に 2021 年 7 月に医療系スタートアップである Ubie 株式会社に入社する運びになりました。ubie.lifeUbie は現在ホットな医療という分野での活躍をねらい、また特色のあるというかクセが強い組織や文化を持っており、これが自分が抱える課題を緩和する材料になると感じたためです。医療 X テクノロジーは挑戦しがいがある代表の阿部の記事の通り、医療分野においてテクノロジーを組み合わせて解決できる課題があり、挑戦しがいがあります。note.com「テクノロジーで人々を適切な医療に案内する」ことで救える命、助けられる人々が居るはずです。もっと身近に言うなら将来の自分を救うことにもなりえます。俺もまだまだ若いし放っておけば直るっしょ、という油断をいつまでできるか分かったものではありません。このコロナ禍で、我々は誰しも当事者になりうるという危機感を植え付けられています。医療と将来の健康状態は今改めて我々の目の前に見える壁として立ちはだかっています。そして課題があるということは、ビジネスチャンスにも満ちていると言えるでしょう。会社の成長に貢献して、対価としての報酬を得る。自分が事業にコミットしている実感が非常に出る状況が揃っていると考えます。ホラクラシー組織と頻繁な異動Ubie ではホラクラシーという組織体系を採っています。詳細は以下にまとまっています。個人的に響いた点として、有機的に組織が変化して異動が頻繁に行われていること、個人が複数のロールに紐付き業務を遂行することが挙げられます。（実際、入社して二日目で自分のメンターが異動してチームから居なくなりました。ワロタ、そんなのってアリ！？）note.comロールベースの働き方は、現在多様な経験を積んで引き出しを増やしたく感じている自分にとってマッチしそうです。 will/can/must がマッチしそうな環境に身を置き、別の道があれば別のロールを探すこともできそうです。これだけ言うと兼務に近いイメージになりますが、 Ubie のホラクラシーではロールを積極的に抜けていく想定でもあり、機動力高く動いていけそうです。さて一風変わったそんな組織にジョインして一ヶ月。現在は「生活者とかかりつけ医をつなぐ」為のプロダクト開発のため、ソフトウェアエンジニアとして動き初めています。先日新サービスに関するプレスも打たれました。prtimes.jp関わる技術スタックとしてはフロントエンドで React(Next.js), TypeScript バックエンドでは Kotlin, Spring Boot, GraphQL などで、正直ほとんど触ったことない（特に TypeScript は入社まで触ったことが全くなかった）要素ばかりです。しかしこれもまた良い刺激でありコンフォートゾーンからの脱出が捗ると考えています。まだまだバリバリのスタートアップである自分が入社した時点で社員数は 100 名超くらいでした。その中でも Web 周りを触ってるソフトウェアエンジニアに限定すると 15 名ほどと少数精鋭部隊になっています。Ubie もエンジニアが少しずつ増えてきたんですが、SWE に絞ると今だに15人くらいしかいない状況です...世界に羽ばたくヘルスケアプロダクトを作りたい方絶賛募集しているので応募してください！https://t.co/gezcIyiibz— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年7月6日  twitter.comということは個々人やれることややるべきことは無限にあるわけです。成長できる要素しかないし、このフェーズの雰囲気を味わえることは非常に価値があります。また会社の規模と事業のフェーズも手伝ってか率直かつ建設的なコミュニケーションが行われています。根回しやプライベートなチャットなど社内政治を避け、かつ同僚にラフにコミュニケーションを取る体制は、自分には快く感じるに加えてバリバリの成長途中感を覚えさせるものになっています。おわりにというわけで、メルカリ・メルペイに 3 年 10 ヶ月在籍しましたスキルや経験の幅を持たせたいサービス初期の雰囲気をまた味わいたくて転職Ubie に入社して SWE として働き出して一ヶ月経過しましたというお話でした。今後ともよろしくお願いいたします。また本記事がなにかの参考になれば幸いです。もし本記事を通して Ubie にご興味を持っていただけた方がいらっしゃいましたら、採用ページあるいは僕に直接ご連絡いただけると幸いです！あんまり興味を持った訳じゃなくて最近どうなの？って話でも振って頂けると喜びます。先述の通り Ubie ではまだまだメンバーを募集しており、更にプロダクト開発を邁進していきたい状況です。SRE やデータエンジニアについては固有の JD があり、recruit.ubie.liferecruit.ubie.lifeWeb 周り触ってるソフトウェアエンジニア（僕の今の本業はここ）についてはこちらになります。recruit.ubie.life

転職しました: メルペイ -> Ubie ~クセつよ組織を求めて~

技術書典9 で「Apache Parquet ではじめる快適 データ分析」を出します。もしよろしければお手にとっていただければ幸いです。まあ今回はオンライン開催で電子書籍のみの配布なので、物理的にお手に取れないんですけどね〜！本書は Apache Parquet についてつらつらと紹介記事を書いた内容になります。また付録的に同サークルメンバー著「USB デバイスを作るのがツラい」というテーマの記事も掲載します。データ分析業務にムッチャ関わる、ストレージコストを最適化したい、 BigQuery などのデータウェアハウスサービスを日常的につかう、なんとなく気になった、ような人々に効果的だと思います。以上よろしくお願いいたします。目次:第1章 Apache Parquet ではじめる快適データ分析 51.1 はじめに .................................. 5 レコード指向フォーマットとは? ..................... 6 カラムナフォーマットとは? ....................... 8 レコード指向とカラムナ、OLTPとOLAP ............... 10 カラムナフォーマットの実装例 ...................... 111.2 ApacheParquetとはなにか........................ 11 並列読み書き処理化しやすいバイナリレイアウト............. 12 スキーマが自己記述的 ........................... 15 シンプルで柔軟性のある型表現 ...................... 15 ネストされたカラムや繰り返しされるカラムに対しても有効 . . . . . . . 16 多様なエンコード方法 ........................... 26 豊富な圧縮コーデックを選択可能 ..................... 31 メタデータを駆使したクエリ最適化が可能 ................ 321.3 ApacheParquet実装例 .......................... 33 parquet-mr................................. 33 ApacheArrowC++実装......................... 34 Goにおける実装例............................. 341.4 実際に使ってみる ............................. 35 Parquetファイルを生成してみる ..................... 35 ParquetファイルにAthenaからクエリしてみる . . . . . . . . . . . . 391.5 実際の運用................................. 42 Parquet で実際どれくらいファイルサイズが削減されるのか? . . . . . 42 RowGroupとPageのサイズのチューニング .............. 42 長期ログ保存におけるコスト削減に寄与できる .............. 42 ストリーム処理に組み込む難しさを考慮する ............... 43 SELECT*に弱い............................. 44 1.6 おわりに .................................. 45付録 AA.1 はじめに .................................. 46A.2 USB通信プロトコル概要 ......................... 46A.3 USBデバイスの設計方針 ......................... 48A.4 USBデバイスが動くまで ......................... 49A.5 USBの消費電力規格............................ 50A.6 地獄のノイズ耐性試験 ........................... 50トグルビット不一致 ............................ 51安物のハブが...... ............................. 52A.7 まとめ ................................... 52あとがき54USB デバイスを作るのがツラい 46@syu_cream .................................... 54 @lunatic_star ................................... 54

技術書典9で「Apache Parquet ではじめる快適 データ分析」を出します

一年以上前の記事だけど、 https://martinfowler.com/ に "Data Mesh" をうたう記事があったので軽く読みました。martinfowler.comこちらに日本語で概要をまとめた記事もありご一読することをおすすめします。僕の個人ブログを見るより確実で良い情報を得られるでしょう。https://www.infoq.com/jp/news/2020/03/distributed-data-mesh/以下では現行のぼくの業務と照らし合わせて、 Data Mesh について個人的解釈などを書いていきます。Current status ...二年くらい前に builderscon で "メルペイにおける、マイクロサービスに寄り添うログ収集基盤" みたいなタイトルで LT で発表したりしました。当時、急速に開発されるマイクロサービス群と元から存在したモノリスなシステムに特化したデータ基盤が存在し、「マイクロサービス化したら分析等のためのデータどうなんの？？？」と漠然とした課題感はあるものの誰も答えを見出だせていない状況でした。 speakerdeck.comそこから二年も経過すると弊データ基盤も色々とあり、上記に挙げた batch/streaming それぞれの要件に特化した仕組みを作ったり刷新したり、公開していないまた別のシステムを構築したりとかしていました。（その辺の最近の話も別途公開していければと思っています）この二年で発生した大きな変化としては、以下の辺りが挙げられるかと思いますビジネスのスケールに対して自分が認知できる範囲が追いつかなくなったマイクロサービスがむっちゃ増えた。俺は数えるのをやめたデータの要件も多種多様になった。種類によるところや性能要件などこの辺りの煽りを受けると、データ基盤もこのような変化に追従できなければ組織の中でのボトルネックになりかねないなという危機感を覚えています。Data Mesh の話という個人的振り返りをしつつ元記事の話題に移ります。データ基盤前史とにかく我々は「サイロ化」という言葉を好んで使い、打ち倒すべき敵みたいに扱います。データのサイロ化もそのやり玉に挙がり、組織やシステム間でデータ連携ができずに分析基盤でうまく扱えない課題を指摘されることがあります。これに対して、データレイクやデータウェアハウスみたいな一元的にデータが管理可能な入れ物を用意して、とりあえずそこにデータを突っ込む道路を舗装して分析業務を回すみたいな解が取られてきたと思います。Data Mesh の記事ではこのような一元的なアーキテクチャを前世代的なものと位置付けています。中央集権的なデータ基盤は全体最適化には良いけれど、個別の高度な要件を満たすのが難しくなります。またデータ基盤はデータの producer / consumer のようなデータの流れに沿った上流・下流の構図を作りがちです。んで、 consumer が要件を満たしたい場合上流に遡りつつデータ基盤屋さんにも相談するような依存関係が生まれます。さらにそうした構図が生まれると中流に位置するデータ基盤のチームは時として producer/consumer のドメイン知識を求められるかもしれません。その振る舞いを行えるメンバーがどれだけ確保できるでしょうか・・・。個人的にはこうしたデータ基盤のモノリス化はなんら不思議ではないと思います。BigQuery はじめとした便利なデータ基盤に使えるシステムが台頭してきてはいますが、データエンジニアリングの領域は未だ職人芸が求められる領域であり、それに特化したスペシャリストが基盤構築を行うのは自然かなと。またデータ基盤構築にあたり、まずデータを一定数揃えないとバリューを出しにくいでしょうから producer に寄った最適化をして「とりあえずデータを集める」「データレイクに突っ込んでから後のことを考える」のは理にかなっていると考えます。とはいえデータ基盤の利用者が増えて、 consumer のリクエストを聞き始めると苦しみが生まれ始めるとも考えられます。自分の実体験としても、黙っててもデータ基盤がワークするケースというのは producer と consumer が同一のチームかあまり距離が遠くないチームのケースが多いような気もしています。データをメッシュにするこの記事における前世代的なデータ基盤の課題の解決方法は、マイクロサービスアーキテクチャさながらモノリスの分解だと考えられます。データメッシュの世界では一元的でモノリスなデータ基盤は存在せず、代わりに広く使われるデータインフラを見るチームと分散したデータ処理システムが存在します。また明確な producer と consumer という立場を生じさせず、各ドメインチームがデータの管理も行い相互にコミュニケーションします。分散することで前述のサイロ化問題が再熱しそうですが、横断的なデータガバナンスの仕組みやセルフサーブ可能なエコシステムを導入していきます。データメッシュの思想は本質的には権限や責務の移譲と、データ基盤が真に基盤らしく振る舞うためのパラダイムシフトを起こすことだと考えます。前者の思想はマイクロサービスアーキテクチャとよくなじみ、データの producer がマイクロサービスであるならばその延長でデータも扱えればいいだけでしょう。データ基盤が基盤本来の仕事に集中するのも重要なことで、データの producer / consumer が増えるにつれ無限にドメイン知識が求められるなら組織のスケーラビリティは死んでいくし、同様の振る舞いができるメンバーを探すのが困難になってくると思います。ぼくの所属する組織では Microservices Platform チームというマイクロサービスを支える基盤を構築するチームが存在し、マイクロサービスを開発運用するにあたり共通課題となる Kubernetes クラスタやデプロイパイプラインの提供を行っています。これに近く各ドメインチームがデータにまつわる課題を解くための共通基盤を提供してセルフサーブ可能にして、しかし自身は課題を解く主役にはならないぐらいのバランスが求められるのかもしれません。tech.mercari.comそう理想は言ってもデータメッシュの世界観に沿うようなツールが無いとこの理想的世界に近づくことはかなわないでしょう。データメッシュの記事では特に GCP のプロダクトについて、一元的なデータガバナンスなら Google Cloud DataCatalog が、バッチ・ストリーミング処理には統合的に扱えインフラがフルマネージドな Google Cloud Dataflow があると挙げています。また筆者の経験ではデータメッシュの世界観でデータレイク的なポジションとして GCS を、ドメインごとに bucket を作成して利用して、データウェアハウスとして BigQuery を使うのもありかと考えます。特に BigQuery は GCP プロジェクトが異なっていても参照する権限があれば JOIN することは可能であり、データメッシュのような論理的には分散したデータ基盤を実現するのにマッチするように感じます。Data Mesh と俺セルフサーブ可能な基盤を目指してなるべくデータ基盤がドメイン知識を抱え込まずコミュニケーションにおけるクリティカルパスにならないようにする思想は重要だと感じます。前世代的な（と言われてしまった）データ基盤では producer/consumer のバリエーションも増えて、その間のコミュニケーションにデータ基盤が入ることでボトルネックを生むことになりかねません。セルフサーブ可能であればある程度「勝手にやってくれ」といえる領域が増えてボトルネックが解消されてゆき、データ基盤チームはより基盤の作り込みに集中することができると思われます。とはいえこれを最初期からゴールに据えるのも骨が折れる作業であると思うので、段階的に分散可能にしていくのが良いかもしれません。最近では弊チームでもセルフサーブ・分散管理可能な設計にしつつ、枯れてくるまでは自チームで面倒を見るという思想で動くことが増えてきました。データガバナンスやデータ処理の分散化そのものについてはやや懐疑的な部分があります。前世代のデータ基盤でも十分多い数の producer が発生するはずで、データメッシュの話とは独立してデータガバナンス、メタデータ管理やリネージ追跡、クオリティチェックなどの課題を考えるべきでしょう。もしかしたらデータ基盤チームがこれらの課題まで人手でカバーしているケースがあるかも知れませんが、それならなおのことデータメッシュの文脈に依らずエコシステムの作り込みをした方が良いように思えます。またデータ処理もまた職人芸が試される領域でありあまり各ドメインチームに移譲しにくいような気もしています。BigQuery などデータウェアハウスに格納してから SQL でなんとかする、みたいな汎用的なシナリオならいざ知らず、低遅延での処理が求められるとか重複除去したいとかリッチな要件が出てくるシナリオで各チームで対応するのが現実的なのかどうか。また、いずれにせよ consumer のようなデータを使う側にある人々をどのようにケアするかは課題になると推測しています。中央集権的なデータ基盤の有無に関わらず consumer が必要なデータを producer に準備してもらう枠組みは必要で、そのコミュニケーションや動機づけをどうすれば解決できるのか自分の中ではアイデアがありません。そこを含めてデータガバナンスで頑張る！という話であるなら、まだ現実の課題に適用するまでに障壁がある気もしております。

Data Mesh の記事を読んだ

Avro と BigQuery の読み込みApache Avro は BigQuery のデータ読み込みに対応したシリアライゼーションフォーマットであり、 Object Container Files フォーマットを採用することでスキーマが自己記述的になり読み込みに際して別途スキーマ情報を与えなくて済むメリットがあります。また BigQuery としては Avro (を含めたいくつかの形式) では平行読み込みが可能とされ、それができない形式、たとえば gzip 圧縮された JSONL 形式などと比較して早く読み込めるようです。cloud.google.com加えて、実は並行読み込みが可能とされてかつ効率的な圧縮が期待できる Avro, Parquet, ORC の中にも読み込み処理において優劣があるようです。Google BigQuery: The Definitive Guide によると "The most efficient expressive format is Avro" とあり、列志向で圧縮もかかる Avro が最も効率的であるとされています。対して Parquet や ORC は行志向であり、これはこれで外部デーブル経由でファイルに直接クエリする分には効率的なものの、 BigQuery に読み込む際には全列読まなければならない分 Avro が有利なようです。そんないい感じっぽい Avro の BigQuery へのデータ読み込み、本記事ではスキーマ周りについていくつか動作を確認してみようと思います。BigQuery にさまざまなスキーマの Avro ファイルを読ませてみる互換があるスキーマで追記する場合まずは replace をせず単純に BigQuery のテーブルにレコードを追加して行こうと思います。とりあえず適当に 1 カラムだけある空テーブルを作っておきます。まずはこれにマッチする単純な Avro ファイルを作って load してみます。$ cat user_v1.avsc{  "name": "User",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    }  ]}$ java -jar ~/tools/avro-tools-1.8.2.jar random --schema-file user_v1.avsc --count 1 user_v1.avro 2>/dev/null$ bq load --project_id syucream-dev --source_format AVRO syucream-dev:test_syucream.user user_v1.avroUpload complete.Waiting on bqjob_r750d0087bb28a293_00000172515bed9d_1 ... (1s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r7bab3c778b4c6a7d_00000172515c7520_1 ... (0s) Current status: DONE+---------------------+|         id          |+---------------------+| 7190660540979993749 |+---------------------+サクッとできました。追記もサクッとできます。$ bq load --project_id syucream-dev --source_format AVRO syucream-dev:test_syucream.user user_v1.avroUpload complete.Waiting on bqjob_r26360ddf0526570_00000172515d711c_1 ... (1s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_rba99937746b1712_00000172515d8f6f_1 ... (0s) Current status: DONE+---------------------+|         id          |+---------------------+| 7190660540979993749 || 7190660540979993749 |+---------------------+このスキーマと互換のあるスキーマを持つ Avro ファイルの load も問題なくできます。$ cat user_v1_1.avsc{  "name": "User",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": ["null", "string"],      "default": null    }  ]}$ java -jar ~/tools/avro-tools-1.8.2.jar random --schema-file user_v1_1.avsc --count 1 user_v1_1.avro 2>/dev/null$ bq load --project_id syucream-dev --source_format AVRO --schema_update_option ALLOW_FIELD_ADDITION syucream-dev:test_syucream.user user_v1_1.avroUpload complete.Waiting on bqjob_r616f9c494daf502a_00000172516056b9_1 ... (0s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r46005fd5ddeefbab_00000172516077d6_1 ... (0s) Current status: DONE+----------------------+------+|          id          | name |+----------------------+------+| -6779445778023123159 | NULL ||  7190660540979993749 | NULL ||  7190660540979993749 | NULL |+----------------------+------+BigQuery のスキーマ的には互換がある追記をする場合今度は前述とは互換性がない、 name フィールドが nullable でなくなったスキーマを持つ Avro ファイルを load してみます。これは成功しますが BigQuery のテーブルとしては name フィールドは nullable のままとなります。（まあ nullable から required の変更は許されていないですしね。。。）$ cat user_v2.avsc{  "name": "User",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    }  ]}$ java -jar ~/tools/avro-tools-1.8.2.jar random --schema-file user_v2.avsc --count 1 user_v2.avro 2>/dev/null$ bq load --project_id syucream-dev --source_format AVRO --schema_update_option ALLOW_FIELD_ADDITION syucream-dev:test_syucream.user user_v2.avroUpload complete.Waiting on bqjob_r5a6eb8678879a075_0000017251620b01_1 ... (1s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r5105091904b8eed0_000001725162d619_1 ... (0s) Current status: DONE+----------------------+-----------------+|          id          |      name       |+----------------------+-----------------+|  3285309633976168209 | twbnsureievqwes ||  7190660540979993749 | NULL            || -6779445778023123159 | NULL            ||  7190660540979993749 | NULL            |+----------------------+-----------------+ここから逆行して最初に load した Avro ファイルを load しようとしても成功します。これはやはり BigQuery のテーブル上では name フィールドは nullable であり、 name フィールドをそもそも持たないレコードの場合は null で埋めればいいからですね。$ bq load --project_id syucream-dev --source_format AVRO syucream-dev:test_syucream.user user_v1.avroUpload complete.Waiting on bqjob_r3e8bbde894d35c3b_00000172516328ff_1 ... (0s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r7e87a10bad564007_00000172516369af_1 ... (0s) Current status: DONE+----------------------+-----------------+|          id          |      name       |+----------------------+-----------------+|  7190660540979993749 | NULL            ||  3285309633976168209 | twbnsureievqwes ||  7190660540979993749 | NULL            || -6779445778023123159 | NULL            ||  7190660540979993749 | NULL            |+----------------------+-----------------+互換がない追記をする場合今度はさらに BigQuery のテーブルとしても互換が取れないであろう変更をしてみます。ここでは required となる age フィールドを追加してみます。この場合、この Avro ファイル単体としては load できそうですが既存のレコードが age フィールドの値をもたないため load できません。$ cat user_v3.avsc{  "name": "User",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    },    {      "name": "age",      "type": "long"    }  ]}$ java -jar ~/tools/avro-tools-1.8.2.jar random --schema-file user_v3.avsc --count 1 user_v3.avro 2>/dev/null$ bq load --project_id syucream-dev --source_format AVRO --schema_update_option ALLOW_FIELD_ADDITION syucream-dev:test_syucream.user user_v3.avroUpload complete.Waiting on bqjob_r6d0dccd4050d198_000001725165f2c9_1 ... (0s) Current status: DONEBigQuery error in load operation: Error processing job 'syucream-dev:bqjob_r6d0dccd4050d198_000001725165f2c9_1': Provided Schema does not match Tablesyucream-dev:test_syucream.user. Cannot add required fields to an existing schema. (field: age)--replace する場合BigQuery のデータ読み込みでは追記ではなくアトミックなテーブルの再生成も行えます。この場合はテーブルとそのスキーマが作り直される都合、前述のスキーマの互換性を気にしなくてよくなります。$ bq load --project_id syucream-dev --replace --source_format AVRO syucream-dev:test_syucream.user user_v1.avroUpload complete.Waiting on bqjob_r1441ed0e2b659303_000001725167e0af_1 ... (0s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r64a104d745d627a1_00000172516817e3_1 ... (0s) Current status: DONE+---------------------+|         id          |+---------------------+| 7190660540979993749 |+---------------------+$ bq load --project_id syucream-dev --replace --source_format AVRO syucream-dev:test_syucream.user user_v1_1.avroUpload complete.Waiting on bqjob_r1254a5673d1c4a55_0000017251684053_1 ... (0s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r542e92fd2eadaefe_0000017251685b41_1 ... (0s) Current status: DONE+----------------------+------+|          id          | name |+----------------------+------+| -6779445778023123159 | NULL |+----------------------+------+$ bq load --project_id syucream-dev --replace --source_format AVRO syucream-dev:test_syucream.user user_v2.avroUpload complete.Waiting on bqjob_r7f71a4c5acbb4a54_00000172516874f8_1 ... (0s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r26844a99b599657a_0000017251688ed0_1 ... (0s) Current status: DONE+---------------------+-----------------+|         id          |      name       |+---------------------+-----------------+| 3285309633976168209 | twbnsureievqwes |+---------------------+-----------------+$ bq load --project_id syucream-dev --replace --source_format AVRO syucream-dev:test_syucream.user user_v3.avroUpload complete.Waiting on bqjob_r3039d309e0eaecd0_000001725168a3bd_1 ... (1s) Current status: DONE$ bq query --nouse_legacy_sql 'SELECT * FROM syucream-dev.test_syucream.user'Waiting on bqjob_r3535c0ed97eae63f_000001725168c9b7_1 ... (0s) Current status: DONE+---------------------+-----------+----------------------+|         id          |   name    |         age          |+---------------------+-----------+----------------------+| 6571829868147110661 | gcypqmwby | -7543339857203188581 |+---------------------+-----------+----------------------+雑なまとめBigQuery による Avro ファイルのデータ読み込みは非常に協力で、 --replace によるテーブル更新によって楽で効果的な運用ができると思います。BigQuery 上でスキーマがどうなるかを考えずに読み込みジョブを実行するだけで良くなるのはメリットが大きいでしょう。ただし --replace ですべてのユースケースが叶えられるわけでもなく、巨大なデータソースから ETL を経て差分更新で同期したいだとかログをひたすら追記したい場合にはスキーマの更新問題がしばしばネックになると思われます。ただその場合でも、BigQuery のテーブルのスキーマとして互換が取れる Avro ファイルであれば読み込み可能であることからスキーマ更新について考える負荷は減りそうです。スキーマ更新が頻繁に発生しうるワークロードでは逆にこの特性を捉えた上でどうテーブル更新するかのワークフローを組むと良いのかもですね。

Avro と BigQuery の load とうまく付き合いたい

先月、さらりと Cloud Dataflow に FlexTemplate という新機能のベータ版がリリースされました。cloud.google.com残念ながらまだあまりドキュメントがなく、これを用いるとなにが嬉しいのかが掴みにくいところです。本記事では FlexTemplate 周りを軽く試してどのような機能で何が嬉しいのか探ってゆきます。従来のテンプレートCloud Dataflow はジョブの一部パラメータを実行時に置き換え可能にしたビルド済みのテンプレートを作ることができます。また Google はこの機能を用いた公式テンプレートを何種類か用意してくれており、 GCP 上のリソースに対してコーディングなく ETL 処理をすることが可能になっています。cloud.google.comちなみにこのテンプレートの機能なのですが、 FlexTemplate の登場の都合からかドキュメント上で "従来のテンプレート" という見出しになってしまったようです。。。実行時にパラメータを置き換え可能にするには、その値を ValueProvider でラップしてあげる必要があります。ValueProvider の実装としてテンプレートのステージング時に静的に値が決まる StaticValueProvider と実行時に決まる RuntimeValueProvider が存在しており、これによりパラメータを渡すタイミングを柔軟に選べます。また Apache Beam の SDK 内の IO 関連ビルダークラスには ValueProvider を受け取って振る舞いを変えてくれるものが多々あります。beam.apache.org逆に言うとこの ValueProvider で賄えないような性質のパラメータは実行時に指定可能なパラメータとして扱えません。これは分かりやすい部分で言うと Beam の SDK のインタフェース的に ValueProvider を受け取ってくれないような部分、もっと複雑な例で言うと内容によってパイプラインのグラフが変わるようなパラメータは扱えません（あるいは扱うのが困難）FlexTemplateFlexTemplate は、おそらくなのですが、与えられるパラメータに柔軟性を与えるものです。ドキュメントだけでは正体が定かにはならないですが、 gcr.io/dataflow-templates-base/java11-template-launcher-base をベースとした Docker image を用いて Dataflow ジョブを実行するようになります。テンプレートジョブの構築手順は「従来のテンプレート」に似ており FlexTemplate によるテンプレートの作成と、実行の 2 つのフェーズがあります。前者では前述の Docker image を GCR に push して、かつその Docker image で解釈可能なパラメータを示した metadata.json を GCS に upload します。 Docker image の build & push は従来のテンプレートでは存在しなかった手順ですね。https://cloud.google.com/dataflow/docs/guides/templates/using-flex-templates#creating_a_flex_template後者では実際にパラメータを与えてジョブを実行します。cloud.google.comこのジョブの実行時に興味深いことに、ジョブの launch 用に GCE インスタンスが開始され先程作成した Docker image が実行されることが見て取れます。この Docker コンテナの動作がよくわからないところですが、内部的にはこのタイミングから Dataflow ジョブのステージングと実行を開始してくれるものと考えられます。#cloud-configs...    ExecStart=/usr/bin/docker run -v /var/log/dataflow/template_launcher:/var/log/dataflow/template_launcher gcr.io/xxx/samples/dataflow/streaming-beam-sql --template-container-args='{"consoleLogsLocation":"gs://xxx/staging/template_launches/xxx/console_logs","environment":{"region":"us-central1","serviceAccountEmail":"xxx","stagingLocation":"gs://xxx/staging","tempLocation":"gs://xxx/tmp"},"jobId":"xxx","jobName":"streaming-beam-sql-20200512-004931","jobObjectLocation":"gs://xxx/staging/template_launches/xxx/job_object","operationResultLocation":"gs://xxx/staging/template_launches/xxx/operaton_result","parameters":{"inputSubscription":"test","outputTable":"foo:bar.baz","stagingLocation":"gs://xxx/staging","tempLocation":"gs://xxx/tmp"},"projectId":"xxx"}'...さてこの FlexTemplate で何が嬉しいのかというと、大きな差異として実行時パラメータを ValueProvider で包む必要が無くなった点があります。FlexTemplate を利用したジョブのサンプルがいくつか公開されているのですが、この内の PipelineOptions の getInputSubscription() など、実行時に指定可能なパラメータでありつつも ValueProvider 型で扱われていないことが見てとれます。github.comこれにより、従来のテンプレートでは課題になっていた ValueProvider を受け取ってくれないような値を実行時に変更したいだとか、パイプラインの構造が変わるようなパラメータを渡したいような部分に効果を発揮するものと思われます。とは言ってもデメリットもあり、ジョブが Queue に入ってから Running の状態になるまで数分待たされる（ステージングのタイミングが遅延したのなら妥当に思えるが）だとか、今のところ Streaming Engine や FlexRS のサポートがないとか課題が存在します。終わりに軽く触れてみた限り FlexTemplate はシンプルな仕組みながら Dataflow のテンプレートに相当な柔軟性を持たせることができそうです。FlexTemplate にどこまでを期待して、どのように従来のテンプレートと棲み分けすべきかのか（上位互換の位置付けなのか？）、今後のサポート具合など気になるところですね。

Cloud Dataflow の FlexTemplate は何者か

先日リリースされた Confluent Platform 5.5 より Protocol Buffers と JSON Schema のサポートが入ったようです。www.confluent.io以前 5.4 を対象に、 Schema Registry を中心に色々記載してみましたが、今回は 5.5 で入ったこの差分を追跡してみます。syucream.hatenablog.jpConfluent Control Center 上でスキーマを管理する定番の Confluent Control Center を使って、ブラウザ上で Schema Registry の設定周りを試してみましょう。試しに protobuf でスキーマを登録してみた状態が以下のとおりです。protobuf において .proto ファイルに記述していくスキーマを登録できるようになっています。JSON Schema の場合は例えば以下のようになります。互換性チェックの挙動を試してみるこれだけでは面白くないので protobuf のスキーマを更新していってみます。まず uint32 age = 3; フィールド追加を行ってみます。フィールド追加は特に互換性を壊しません。というわけでスキーマの更新も無事に行なえます。syntax = "proto3";message value_protobuf {  uint64 id = 1;  string name = 2;  uint32 age = 3;}今度は field number を変更してみます。早速さきほど追加したフィールドを  uint32 age = 42; に書き換えてみました。この変更もリスクはありそうですが、スキーマ更新は受け入れられます。syntax = "proto3";message value_protobuf {  uint64 id = 1;  string name = 2;  uint32 age = 42;}さらにフィールドの削除やフィールド名の変更も受け入れられます。syntax = "proto3";message value_protobuf {  uint64 id = 1;  string fullname = 2;}これらの変更は互換性を壊すものではないのでしょうか？ Confluent Schema Registry での protobuf の互換性チェックの仕様は以下の通りになっています。docs.confluent.ioおおむね protobuf の wire format の解釈に影響を及ぼさず、デシリアライズは無事行えるような内容であれば互換性が維持されると見るようです。フィールド名の変更に対する言及は明記されていませんが、これも wire format の解釈に影響しないからだと思われます。・・・ただ実際にはデシリアライズには成功するとしても後続のデータ処理が影響を受けないかどうかは保証されないでしょうし注意が必要です。フィールドの追加や削除は予期せぬ値のデフォルト値化、フィールド名のリネームはフィールド名を意識した後続処理で問題が発生するかも知れません。ここから明確に互換性が無い変更も行ってみます。このフィールドの型 uint32 を string にしてみます。この場合は予想通り互換性が無いとされてスキーマ更新が拒否されます。// 筆者はこの他にも JSON Schema のスキーマ変更も試してみたのですが、互換性チェックの挙動が読めず諦めてしまいました。protobuf の扱い周りの実装を読んで見る5.5 でサポートされたデータフォーマットのバリエーションと各フォーマットの扱いはどうなっているのでしょう。せっかくなので前節で触れた protobuf 周りの実装を追ってみます。protobuf 対応した Serializer/Deserializerドキュメントから、データフォーマット毎に Serializer, Deserializer の実装が異なるようです。まずはここをエントリポイントとしてみます。docs.confluent.ioAvro と同様 AbstractKafkaProtobufSerializer, AbstractKafkaProtobufDeserializer に、 protobuf のデータである Message のサブクラスのオブジェクトのシリアライズ・デシリアライズ処理と schema registry とのやり取りの処理が実装されています。ここで protobuf のスキーマ情報は公式の Descriptor としてではなくラップされた型として扱われます。また protobuf は import 文で他の .proto ファイルを読み込むことができるのですが、この依存関係を解決するロジックも持ち合わせています。面白い点として Serializer は protobuf の、 protoc で生成された具体的なメッセージクラス (Avro でいう SpecificRecord みたいなもの)を扱い、 Deserializer では DynamicMessage (Avro でいう GenericRecord みたいなもの) を扱うことです。producer は .proto の記述に従ったメッセージクラスが使えますが、それを consumer が持っている保証はないため妥当な扱いだと思われます。複数データフォーマットをサポートしたスキーマの表現5.4 では Schema Registry として考慮していたスキーマが Avro しかありえなかったので、 Schema Registry としては Avro の Schema クラスを扱うような実装になっています。これが 5.5 では ParsedSchema インタフェースという一段抽象化された構造で扱われます。protobuf のスキーマを表現する ProtobufSchema、 Avro の AvroSchema, JSON Schema の JsonSchema はそれぞれ ParsedSchema を実装しています。個々の ParsedSchema 実装の中でスキーマ固有の処理、互換性チェックや protobuf で言う descriptor の扱いなどを担います。おわりに簡潔に追っただけですが、妥当な進化を遂げたような Confluent Platform 5.5 でした。protobuf はコード事前生成を想定した利用シーンが多いですが、 Confluent Platform でのサポートなど利用シーンが増えてくると活用できる機会がさらに増えるかも知れません。また今回複数データフォーマットのサポートが入った以外にも ksqldb という KSQL の進化系？のような機構が増えて Confluent Platform も進化を続けている印象を受けますね。

Schema Registry について書いていく: Confluent Schema Registry の Protocol Buffers & JSON Schema サポート

Protocol Buffer wire format についてProtocol Buffer でシリアライズされた後のバイナリのレイアウトの仕様は wire format の仕様という形で独立してドキュメントが用意されています。この wire format の仕様は見ればわかる通りそれほど記述量が多くなく、それでいて互換性を気にしつつ、かつ拡張の邪魔にならないような配慮がされています。developers.google.comwire format として特に重要な点は以下の通りだと個人的には考えます。整数型に対するデータサイズがなるべく小さくなるような工夫がされている複雑な型はバイト配列に押し込める。（多くのシリアライゼーションフォーマットと同じように）長さが指定されたバイト配列として表現フィールドの順序が任意にできる。のでスキーマ更新において順序を意識しなくてよくなる。wire format では各フィールドはフィールド番号と wire format 上での型で識別されます。これらを元に、 .proto ファイルでどう記述されていたのかに対応してより具体的な型として解釈したりフィールドの名前を取得したりできるわけです。例えば field number が 10 、 wire type が 2(バイト配列) であった場合に、 .proto では string name = 10; という対応する field number があるならフィールド名は name でありバイト配列は文字列として解釈できそうだと判断できます。とはいえシリアライズ済みバイナリを頻繁に扱ってくると、ましてや複数のシステムでデータ交換をし出すと時には .proto や descriptor 、ライブラリなしに内容を確認したい時があるかも知れません。特にデータ交換を行う場合システム間で持つスキーマが異なる場合にはこの希望は大きくなるかもです。またパースエラーが起こる箇所を絞り込みたいなどの要望から、スキーマを用いた具体的なデータの解釈をなるべく遅らせたい場合にこの戦略は有効かも知れません。そんなことを考え、 Go で無理やりシリアライズ済みバイナリを、それ単体の持つ情報だけで解釈してみる試みをしました。Protocol Buffer without schemaというわけで Go で schema less で protobuf のデータを無理やり解釈するコードを書いてみました。github.comwire format のフィールドの解釈は protowire という既存のモジュールがあり、詳細な部分は概ねこれで行えます。wire format の解釈の上で面倒くさい点は可変長になりうる varint の値や ZigZag encoding されうる signed integer あたりですがこのあたりは実装されてくれています。godoc.orgバイト列の詳細な解釈は descriptor の情報が無いと正確な値は取れません。ここでは雑に、思いつく範囲の解釈を全部試して wire format としては valid な値をすべて返すようにしています。具体的には文字列とバイト列、ネストされたメッセージ、整数型の repeated な値などです。そのほかにも Protocol Buffer としてはバイト列で map 型が表現できるのですが、これについては wire format やその他のドキュメントに詳細な仕様がなく（うまく見つけてなくてどこかに存在するかも？）一旦諦めています。Go の実装的にはバイト列の中に更にネストされたメッセージに似てフィールド番号や wire type が指定されたフィールド列が存在して、フィールド番号が 1 であれば map の key 、 2 であれば value となるようです。github.comこれを用いて以下のような .proto のメッセージをこんな様な値を設定してシリアライズした時の               msg := &protosl.Example{                    Uint64Val:  1,                    StringVal:  "testing",                    Fixed64Val: 11,                    Fixed32Val: 111,                    EnumVal:    protosl.Example_ONE,                    ChildVal: &protosl.Child{                        V: 1,                    },                    RUint64Val: []uint64{2, 3},                    RStringVal: []string{"aaa", "bbb"},                    // RFixed64Val: []uint64{22, 33}, TODO repeated fixed isn't supported                    // RFixed32Val: []uint32{222, 333}, TODO repeated fixed isn't supported                    REnumVal: []protosl.Example_Num{protosl.Example_ZERO, protosl.Example_ONE},                    RChildVal: []*protosl.Child{                        {                            V: 2,                        },                        {                            V: 3,                        },                    },                }シリアライズ後のバイナリを食わせると、かなり冗長にはなりますが以下のように解釈できます。$ echo -n "\x08\x01\x12\x07\x74\x65\x73\x74\x69\x6e\x67\x19\x0b\x00\x00\x00\x00\x00\x00\x00\x25\x6f\x00\x00\x00\x28\x01\x32\x02\x08\x01\xaa\x06\x02\x02\x03\xb2\x06\x03\x61\x61\x61\xb2\x06\x03\x62\x62\x62\xca\x06\x02\x00\x01\xd2\x06\x02\x08\x02\xd2\x06\x02\x08\x03" | protosl{"1":1,"101":{"__bytes":"AgM=","__packed":[2,3],"__string":"\u0002\u0003"},"102":[{"__bytes":"YWFh","__packed":[97,97,97],"__string":"aaa"},{"__bytes":"YmJi","__packed":[98,98,98],"__string":"bbb"}],"105":{"__bytes":"AAE=","__packed":[0,1],"__string":"\u0000\u0001"},"106":[{"__bytes":"CAI=","__message":{"1":2},"__packed":[8,2],"__string":"\u0008\u0002"},{"__bytes":"CAM=","__message":{"1":3},"__packed":[8,3],"__string":"\u0008\u0003"}],"2":{"__bytes":"dGVzdGluZw==","__packed":[116,101,115,116,105,110,103],"__string":"testing"},"3":11,"4":111,"5":1,"6":{"__bytes":"CAE=","__message":{"1":1},"__packed":[8,1],"__string":"\u0008\u0001"}}バイナリを直接確認できると何かしら便利、フィールドとの対応付けは後で行うので・・・という時に役のに立つかも知れません。

protobuf のシリアライズ済みバイナリを無理やり読む

タイトルの通りで単なる日記なのですが、今の心境を赤裸々に綴っておくと後で振り返れると思いつらつら書きます。なおこのエントリは個人の意見ですし、同じ会社同じチームでも受け取り方や課題感はだいぶ差異が出るんじゃないかなーと思っています。二ヶ月前からこれまで今年 2 月 19 日に新型コロナウイルス蔓延を受けて、勤め先が以下のようなプレスを出しました。about.mercari.comこの段階で大規模にリモートワークに転換する企業はそう多くなく、このときは代表例としては GMO さん、ついでドワンゴさんあたりが原則リモートワークで業務をすることを宣言していた記憶があります。東京都内のこの時の状況としては、少ないながらも感染事例が挙げられつつあり、会社として特に方針が無くともチームとして満員電車の通勤を避けたいななどと話していたりしました。そういう情勢だったので会社として早めに方針が打ち出されたのはいち従業員としては行動方針を決めやすくもありありがたいものでした。チーム的には Slack ベースのコミュニケーションを盛んにやっており、リモート勤務に必要な設備もチームメンバーがそれほど障壁なく行えたのは幸いでした。WIAS という勤怠管理システムのお世話にもこの頃からなり始めました。tech.mercari.comさて原則 WFH はそれほど課題なく継続されて、一ヶ月が経過してお花見シーズンになる頃には世間的にも緩みが出てきて、チーム的にも週一くらいで出社して社会復帰してみよう（？）という雰囲気が出てきました。その矢先に永寿総合病院における院内感染が発生して（通勤経路や生活圏的にこのあたりで僕は余計に危機感を覚えたのですが）、緩み始めたムードは一点します。より強く WFH を求められるようになり、世間のニュースも仄暗いものばかりになってきます。その傾向は緩むどころか悪化するばかりで、やがて緊急事態宣言に至り、本稿執筆時は多くの飲食店等が活動を休止して街はすっかり息をひそめています。WFH を続けてみた所感そんな具合で世間的には比較的早く原則 WFH の働き方に切り替えて二ヶ月経過した訳ですが。WFH だから被った被害ややりにくさというのはそれほど無いと考えています。ただしホワイトボードなどを使って集団でブレストしたり、ふらっと立ち話風に同僚に声かけて相談するという行動がしにくくなったのは損失ではあります。ただ致命的ではないとも。また僕の場合は部屋が狭く（自宅の快適さより通勤の快適さに重きを置いていた）、働くのにあまり適さない自宅環境だったのも大きな課題でした。今回の件で一番の問題は WFH で勤務することそれ自体でなく新型コロナウイルス蔓延の先行きが見えず、時には大きく状況が悪化することがあった部分だと思います。働き方というか働くことというか、それ以前に世間を取り巻く状況が悪く、精神衛生に良くないのがもっとも辛い。とりあえずこの先生きのこるには直近試しているのはとにかく作業環境の改善です。1K 限界一人暮らし部屋はそのままでいると漏れなく仕事場所がベッドルームと同一存在になります。これに耐えられる人は良いのでしょうが、僕は耐えられませんでした。この課題に対して理想的にはさっさと引っ越し！したいところですが、不要不急の外出を自粛するよう求められた我々にできることは限界があります。というわけで妥協案としてクローゼットの中のものを外に追いやるか思い切って処分してスペースを構築して、クローゼット内部を作業場所にするようにしました。部屋が狭く作業スペースを確保しにくいことについカッとなってクローゼットを簡易作業スペースにしてしまった pic.twitter.com/H5neupDO7t— しゅー　くりーむ (@syu_cream) 2020年4月8日  このようなクローゼットの活用の仕方には「クロッフィス」と呼ばれることがあるようです（どれくらい知名度があるかは知らん）weboo.link今ではカーテンで簡易仕切りを設けたり造花で草を生やしたり最適化を進めています。クローゼットを潰して作った作業スペース、謎の進化をし始めている pic.twitter.com/ZPtbcKbfyM— しゅー　くりーむ (@syu_cream) 2020年4月20日  そして精神衛生に悪い状況であることは、もうしょうがない。しばらくは今回の騒動が起こる前と同じようには働けないと、諦めることにしています。逆にこの状況の変化で生産性が向上するのならそれはとてもすごいこと。だけどそうそう起こらないこと。つけ加えるなら、メンタルが弱った自覚が出てるうちにさっさと有給を取るなりして休んでしまうのが良いとも思っています。ねてればなおる、しらんけど。

原則 WFH 勤務が開始して二ヶ月が経過した

BigQuery ではユーザ定義関数(UDF) を作ることができる。これを使って、よく使われる式や関数呼び出しの組み合わせを名前付けして再利用できる。cloud.google.comUDF は SQL と JavaScript の二種類の言語による記述が可能で、後者は色々なトリッキーな利用例も世に出ているので知っている人も多いかも知れない。例えば WebAssembly のコードを実行するとかである。medium.com本記事では 地味な方 素直な SQL での記述による UDF について色々挙動を確認してみる。戻り値の型を推論してくれるUDF は例えばシンプルなものだと以下のように記述できる。CREATE TEMP FUNCTION  zero()  RETURNS INT64 AS (0);SELECT  zero()ここで戻り値の型は省略することができる（勝手に解決してくれる）CREATE TEMP FUNCTION  zero()  AS (0);SELECT  zero()STRUCT 型の戻り値も推論してくれる。が、もちろん各フィールド名の情報はないのでダミーの値が補完されてしまう。CREATE TEMP FUNCTION  user()  AS ((1, "taro"));SELECT  user()[  {    "f0_": {      "_field_1": "1",      "_field_2": "taro"    }  }]RETURNS で型を明示するとそこに記述されたフィールド名を拾ってくれる。CREATE TEMP FUNCTION  user()  RETURNS STRUCT<id INT64, name STRING>  AS ((1, "taro"));SELECT  user()[  {    "f0_": {      "id": "1",      "name": "taro"    }  }]UDF から UDF を呼ぶ際はすでに定義済みである必要があるUDF から別の UDF を呼び出すこともできる。CREATE TEMP FUNCTION  callee() AS (42);CREATE TEMP FUNCTION  caller() AS (callee());SELECT  caller()この定義順序を逆にするとクエリの実行が通らなくなる。 Function not found: callee; failed to parse CREATE [TEMP] FUNCTION statement at [5:16] というエラーが出てしまう。CREATE TEMP FUNCTION  caller() AS (callee());  -- <- Function not found :(CREATE TEMP FUNCTION  callee() AS (42);SELECT  caller()UDF の再帰呼び出しをすることもできない。この例では Function not found: fib; failed to parse CREATE [TEMP] FUNCTION statement at [10:7] と怒られてしまう。CREATE TEMP FUNCTION  fib(n INT64) AS (  IF    ( n > 2,      fib(n - 1) + fib(n - 2),      1 ) );SELECT  fib(2)だったら一度ダミーの UDF を定義してみよう！ということで一時 UDF じゃなく永続 UDF を、一度ダミーのものを定義したあと REPLACE してみる。このクエリはそれ自体は valid と言われ実行可能である。-- dummyCREATE OR REPLACE FUNCTION  udfs.fib(n INT64) AS (1); CREATE OR REPLACE FUNCTION  udfs.fib(n INT64) AS (  IF    ( n > 2,      udfs.fib(n - 1) + udfs.fib(n - 2),      1 ) );SELECT  udfs.fib(2)が、これは実行してみると Query error: Too many nested views/persistent user-defined functions or possible circular reference of views/persistent user-defined functions referenced in query. Only 16 levels of nested views/persistent user-defined functions are allowed. at [11:1] と怒られてしまう。 UDF では 16 チェーンまでしか UDF 呼び出しをできない制限がありそれに引っかかっているように見えるエラーメッセージである。この例では udfs.fib(2) を呼び出してもそもそも再帰呼び出しされない気がするが・・・。cloud.google.com頑張ればループ処理を書けるUDF では前述の通り再帰呼び出しできず、ループするような制御構文もサポートされていない。が、 ARRAY 型の値と ARRAY 型関連関数を使うとループ、リストの各要素に対する繰り返し処理的なことができる。ミソとなるのがみんな大好き UNNEST() でテーブルを手にいれることができることと、 ARRAY() の引数はサブクエリを取れる辺りにある！CREATE TEMP FUNCTION  array_twice(n INT64) AS (ARRAY(    SELECT      AS STRUCT (      SELECT        ARRAY_AGG(vv)      FROM (        SELECT          v * 2  -- <- like a map function        FROM          UNNEST(GENERATE_ARRAY(1, n)) AS v) AS vv)));SELECT  array_twice(100)テーブルを参照することもできる上記より SELECT 文が打てることを確認できたので FROM 句に実テーブルを渡してみる。このクエリも合法で実行することができる！CREATE TEMP FUNCTION  do() AS (ARRAY(    SELECT      AS STRUCT (      SELECT        ARRAY_AGG(vv)      FROM (        SELECT          LENGTH(repo_name)  -- <- like a map function        FROM          `bigquery-public-data.github_repos.licenses` -- <- refer to a table        LIMIT          10) AS vv)));SELECT  do()ドキュメントにテーブル参照に関する記述があるので、この挙動は一応想定されたもののはず。（もしかしたら他のまっとうな参照方法があるのかも）一意の UDF とテーブル参照を合わせたクエリあたりの最大数 - 1,000。完全な展開後に、UDF ごとに一意のテーブルと UDF を合わせて 1,000 個まで参照できます。cloud.google.com

BigQuery SQL UDF の挙動を色々確認する

去年末になりますが、 embulk-output-s3_parquet という Embulk Plugin にて Logical Type をサポートするためのパッチを書き、マージしていただきました。github.com個人的な主な目的は timestamp 型をサポートすることでした。 Athena や BigQuery から参照するにあたり timestamp 型として扱えるか否かで使い勝手は大きく変わります。Logical Type としての扱いを期待するかを設定に書く必要はあるものの、割と簡素な設定で timestamp 型対応ができるようになったのではないかと思います。さてこの Logical Type ですが、 2020 年 2 月現在 2 種類の仕様が混在してかつ古い仕様が事実上スタンダードになっている状態です。自分は最初混乱したのですが、この不幸の連鎖を止めたいので、本記事に自分が把握した状態を記録しておきます。古い仕様 "Converted Types"ここまで一口に "Logical Types" といってしまったのですが、ドキュメント上は古い仕様は Converted Types, 新しい仕様が Logical Types と区別されます。そして現在使われる Logical Types としてはこの Converted Types が一般的でしょう。github.com前提として、 Parquet がサポートする型 は以下のものになります。BOOLEANINT32INT64INT96FLOATDOUBLEBYTE_ARRAYConverted Types ではこれらの型に別解釈を与えることができます。これは OriginalType に定義されています。（このクラス名からか、 JIRA や GitHub 上のやり取りを見ると Converted Types のことを Original Types と呼ぶこともあるっぽい？ようです。 Java 実装に限った話かも）MAP,LIST,UTF8,MAP_KEY_VALUE,ENUM,DECIMAL,DATE,TIME_MILLIS,TIME_MICROS,TIMESTAMP_MILLIS,TIMESTAMP_MICROS,UINT_8,UINT_16,UINT_32,UINT_64,INT_8,INT_16,INT_32,INT_64,JSON,BSON,INTERVALembulk-output-s3_parquet でサポートする timestamp 型はここに現れる TIMESTAMP_MILLIS, TIMESTAMP_MICROS になります！また Parquet では文字列型がこの Converted Types の UTF8 OriginalType を使って表現されます。そのため、Parquet の Converted Types は例えば Avro における Logical Types よりは多くのユーザが触れる機会がある概念かも知れません。新しい仕様 "Logical Types"新しい Logical Types は UUID やナノ秒精度 timestamp などさらにリッチな型をサポートしていたり、 Builder パターンでのスキーマ構築をサポートしていたりと様々な更新を含みます。Converted Types との互換性も考慮されており、互換がある表現の場合は変換メソッドも提供されます。これは Parquet 1.11.0 からサポートされているのですが、 maven central repository に上がったのが 2019 年 11 月でありまだ歴史が浅い機能といえます。ミドルウェアの対応としても、 Hive でサポート開始がされ始めた ようですが Spark はまだ だったり普及するのにはまだ時間を要しそうです。BigQuery などクラウドサービスにおいても、スケジュールは定かではないですが、サポートするにしてももうしばらく時間が必要かも知れません。そんな訳で 2020 年 2 月現在、まだ多くの場合は Converted Types を利用することになると思うのですが、将来的に Logical Types に置き換えることや変換メソッドがあることを知っておくと良いでしょう。またドキュメントは新しい Logical Types に関する記述の方が増えていくと思われ、現行２つの仕様がありドキュメントの記述と自分が必要としてい仕様がどちらのものか意識することがしばらく必要かも知れません。

Apache Parquet の Logical Types に関するメモ

分散アプリケーション間のメッセージングやログ収集基盤において、しばしばスキーマの扱いは便利である反面頭を悩ませる種になります。スキーマを厳密に定義して、 Protocol Buffers や Avro などのシリアライゼーションフォーマットを用いることで、メッセージのサイズの減少やメッセージの扱いの安全性を実行時より早く検出できる機会が増えます。しかしスキーマの互換性に気をつけたり、メッセージをシリアライズ・デシリアライズするアプリケーション間でスキーマ情報をどう共有するかの課題も発生します。この課題は、昨年発売された "データ指向アプリケーションデザイン" でも "4.1.4.3 そもそもライターのスキーマとは何なのか？" などで触れられています。世の中にはこの課題を解決するための "スキーマレジストリ" と呼ばれるソフトウェア、サービスがいくつか存在します。残念ながら日本語の資料があまり無いようにも感じますし、筆者の気が済むか飽きるまで様々なスキーマレジストリを探索してみようかと思います。第一回は Confluent Schema Registry について調べてみます。（残念ながら筆者は Confluent Schema Registry を実務で触れた経験がなく、なにか内容に誤りがある可能性があります）Confluent Schema Registry とはConfluent Schema Registry は、マネージドな Apache Kafka を提供する Confluent 社 が開発したスキーマレジストリです。docs.confluent.io以下のような機能を持っています。Apache Kafka に組み込む想定で、 Apache Avro のスキーマを管理Subject 名というスキーマレジストリ用のスキーマ解決の為のキー情報を持つKafka の専用 topic にスキーマ情報を格納する互換性チェックの機構を持つREST API を提供する管理用の WebUI でスキーマ管理を行えるApache Avro については以前本ブログで触れましたし世の中にドキュメントが多数存在するのでここでは別段触れません。スキーマは Subject という識別に用いる名前とバージョン番号で管理されます。Subject をどう決めるかはいくつかのオプションがあり、デフォルトでは topic 名になっています。topic 名を用いる場合はある topic に流れるレコードのスキーマは一つに限定され、複数の異なるスキーマのレコードを流すことは出来ません。これを行いたい場合は他にレコード名もしくは topic 名とレコード名の組み合わせを Subject として用いることになります。スキーマ情報の格納先がそれもまた Kafka であるのはちょっとユニークな点と言えそうです。デフォルトではシングルパーティションの _schemas topic にスキーマ情報を格納するようです。docs.confluent.ioスキーマレジストリという機構の悩ましい点として、それ自体がメッセージバスと同等くらいの可用性を求められることが挙げられます。メッセージバスが生きていてもスキーマレジストリが死んでいるなら、シリアライズする時に用いたスキーマを何処にも格納できず、デシリアライズする側のシステムに伝える術も失うためです。Confluent Schema Registry ではスキーマレジストリの REST API を提供する HTTP サーバの可用性の懸念は残りますが、ストレージは Kafka それ自体と運命共同体になるため考える課題が一つ減りそうです。Confluent Schema Registry は更にスキーマの更新問題にも解決策をもらたします。アプリケーションを稼働させていくうちにスキーマを更新したくなるシーンが登場するのは自然なことでしょう。この際に Confluent Schema Registry は Kafka の Producer が作成した Avro のスキーマは解決してくれますが、 Consumer 側にも配慮する必要があります。例えば Consumer が必要としているフィールドがある日 Producer が送信するレコードから無断で削除されたなら、 Consumer 側で何らかの問題が出るかもしれません。この問題に配慮するため、 Confluent Schema Registry ではスキーマの互換性チェックの機構を設けています。互換性には前方互換性、後方互換性、完全互換性の 3 タイプが設けられています。docs.confluent.io前方互換性は Producer が Consumer より先にスキーマを更新するパターンで求められる互換性です。この場合フィールドの追加もしくは optional 、すなわちデフォルト値を持つフィールドの削除が許されています。これらの変更が行われても Consumer は、自分が知らない追加フィールドは無視する、削除されたフィールドはデフォルト値で埋めることができます。後方互換性は Consumer が Producer より先にスキーマを更新するパターンで求められる互換性です。この場合は前述の逆で、 optional なフィールドの追加とフィールドの削除が許されています。この互換性タイプが Confluent Schema Registry のデフォルトの互換性モードであり、現実世界で気を使われることが多いものであると思います。完全互換性は Producer と Consumer どちらが先にスキーマを更新しても良いパターンで求められる互換性です。この場合は制約が最も弱いようなスキーマ更新、つまり optional なフィールドの追加・削除が許されるようになります。この互換性タイプは制約が弱いため扱いにも困るケースが出るかも知れませんが、 Confluent のプラットフォーム以外のミドルウェアやキャッシュ機構が存在したり処理するレコードの順序が保証されなかったりするケースに、互換性の問題で Consumer 側でエラーが発生するケースを低減できそうです。Confluent Schema Registry はスキーマを更新しようとする際に、求められるタイプに従って互換性をチェックする機能を提供します。REST API は実際に Confluent Schema Registry に対応した SerDe でスキーマ操作を行う際に使われる API にもなります。手動で REST API を叩いてスキーマ登録を行うなどをしても良いでしょう。この API の仕様は以下にまとまっています。docs.confluent.io管理用の WebUI については実際に触れてみた方が話が早そうです。次に触れてみましょう。Confluent Schema Registry に実際に触れてみるクイックスタート公式で Docker イメージと docker-compose yml ファイルが提供されており、とりあえず動かす敷居が低めになっています。docs.confluent.ioこのドキュメントに沿って Docker コンテナを動かした後にブラウザ上で http://localhost:9021/ にアクセスしてみます。上手く動いていれば以下のような管理画面を閲覧できるはずです。Avro のスキーマを登録してみるここでは実験用に hello topic を作成して、この topic に流すレコードの value のスキーマを設定してみようと思います。ここではバージョン 1 のスキーマとして以下を与えてみます。{  "name": "Hello",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    }  ]}登録したスキーマを WebUI 上で確認できます。一度スキーマを登録すると互換性モードを選べるようになります。ここでは一つ前のバージョンのスキーマと後方互換性を保つモードである Backward に設定しておきます。Avro のスキーマを更新してみる; 互換性がある場合先程登録したスキーマを更新してみようと思います。ここでは年齢を指定する想定で {"name": "age", "type": ["null", "long"], "default": null} という nullable なフィールドを追加してみます。{  "name": "Hello",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    },    {      "name": "age",      "type": ["null", "long"],      "default": null    }  ]}このスキーマ変更は optional なフィールド追加に相当して後方互換性チェックをパスすることができます。無事 WebUI からも新しいバージョンのスキーマを閲覧することができています。diff 表示も出来ていい感じです。Avro のスキーマを更新してみる; 互換性がない場合ここから後方互換性が無い変更をしてみます。よく考えたらこのレコードをアプリケーション上で作成した時刻の timestamp 値を保持したくなってきました。ということで optional でないフィールド {"name": "created_at", "type": "long", "logicalType": "timestamp-millis"} を追加してみます。{  "name": "Hello",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    },    {      "name": "age",      "type": ["null", "long"],      "default": null    },    {      "name": "created_at",      "type": "long",      "logicalType": "timestamp-millis"    }  ]}しかしながら先述の通り後方互換性を保つには optional なフィールド追加は許されません。この場合 Confluent Schema Registry が互換性が保てない旨のメッセージを出してスキーマの更新が拒否されます。このように Confluent Schema Registry では、スキーマの管理と共に、求められる互換性のタイプに従ってそれを維持するようチェックをかけてくれます。本当はスキーマ管理を .avsc ファイルなどで保存して CI で互換性チェックし、パスすればスキーマ更新するなど人間による直接の更新を避けるのが望ましいかもですが、この WebUI と互換性チェック機構で人間による直接管理もある程度運用に耐えるかもしれません。余談; _schemas topicWebUI 上では _schemas topic の様子も確認することができます。log.cleanup.policy が delete ではなく compact が設定されており、これにより時間経過等によるレコードの削除を抑制しています。Confluent Schema Registry の実装を覗いてみるConfluent Schema Registry のコードはGitHub で公開されています。折角なのでどんな実装になっているか少し覗いてみます。ちなみにここでは網羅性などは全く考慮していません。筆者が気になるポイントを勝手にかいつまんでいます。github.comここで紹介する内容は v5.4.0 時点のものとなります。avro-serializer: Schema Registry と通信した結果でシリアライズ・デシリアライズを行うこの module に存在するのが、実際に producer, consumer を実装する際に properties に指定する serializer, deserializer になります。シリアライズのコアの実装が AbstractKafkaAvroSerializer の serializeImpl() に存在します。自動登録する設定になっているなら Avro スキーマをスキーマレジストリに登録し、その後 Kafka の topic に送信するメッセージをシリアライズします。この時のバイナリレイアウトなのですが、 この Serializer 実装特有のフォーマットになっており Avro のレコードの手前に 8 バイトのマジックナンバーとスキーマの ID が埋め込まれています。Avro のレコードのバイナリはおなじみ SpecificDatumWriter, ReflectDatumWriter, あるいは GenericDatumWriter で書き出します。docs.confluent.ioこれに対応してデシリアライズ側の実装は AbstractKafkaAvroDeserializer クラスに多くのロジックが持たれています。まずは deserialize() ですがリーダ側のスキーマが渡せるようになっており、デシリアライズの結果をライター側とは異なる（しかし互換性はある）型に展開できるようになっています。ライター側のスキーマは勿論スキーマレジストリ経由で解決できます。この辺りの実装は  AbstractKafkaAvroDeserializer の内部クラスの DeserializationContext クラスで行われます。このクラスに渡された、デシリアライズ対象のバイナリは、先頭 8 バイトにマジックナンバーとスキーマ ID が存在するはすです。まずマジックナンバーの存在チェックを行った後にスキーマ ID を取り出し、この ID をスキーマレジストリに問い合わせて Avro のスキーマ情報を取得します。その後はやはりおなじみ SpecificDatumReader, ReflectDatumReader, GenericDatumReader で Java のオブジェクトとして読み出します。これで概ね Avro のレコードのシリアライズとデシリアライズの流れが掴めますが、スキーマの登録と取得がどのように成されているのでしょうか。先述の Serializer, Deserializer の共通の親クラスとして AbstractKafkaAvroSerDe があり、このクラスがデフォルトでは CachedSchemaRegistryClient というスキーマレジストリに対するクライアントを保持しています。このクライアントの実装がどうなっているのか、次はスキーマレジストリとの通信を行っている client module も覗いてみます。client: Schema Registry のクライアントSchemaRegistryClient インタフェースを実装したクラスが実際に Schema Registry と通信しています。先述の CachedSchemaRegistryClient はその 1 実装であり、スキーマや ID, バージョン情報のキャッシュと RestService というクラスのメンバを持ちます。そして RestService が実際に HTTP リクエストをスキーマレジストリの REST API に送信する、例えばスキーマの登録時に /subjects/:subject/versions に POST リクエストを送る、というような格好になります。core: Schema Registry のコア実装もうひとつ、スキーマレジストリの REST API サーバを提供する core モジュールも気になる存在です。REST API の実装やスキーマ情報などの永続化をどのように行っているのでしょうか。スキーマレジストリの REST API サーバは Jetty + Jersey で実装されているようです。API の各エンドポイントは JAX-RS の Resource として実装されており、例えば /subjects/{subject}/versions であれば SubjectVersionsResource が相当する、などの構成になっています。スキーマなどの情報を永続化するストレージレイヤは KafkaStore クラスで提供されています。スキーマの登録のため put() が呼ばれると、スキーマ情報を ProducerRecord に包んで _schemas topic に 送ります。他方、スキーマの情報取得はというと KafkaStore 自体では直接は _schemas topic を consume せず、別スレッドで動作してローカルスキーマキャッシュを更新する KafkaStoreReaderThread が更新した InMemoryCache から取得する格好になります。この動作についてはドキュメントでも言及されています。docs.confluent.ioおわりにConfluent Schema Registry について筆者の思うまま気になるところをざっくり紹介しました。いかがでしたでしょうか。次回は Apache Pulsar の持つ Schema Registry 機能について調べて行こうかなと思います。なんとこちらのスキーマレジストリは Avro は勿論 Protocol Buffers もサポートしているようです！Protocol Buffers は各言語向けの自動生成されたライブラリを使う、 Avro で言う SpecificRecord のサブクラスに近い性質を持つ表現で扱われることが多いと思われますが、スキーマレジストリをどのように提供しているのでしょうか。pulsar.apache.org余談ですが本記事執筆中に Confluent Schema Registry でも Protocol Buffers をサポートする気配のある pull request を発見してしまいました。近い将来 Avro 以外でシリアライズしたレコードが色んなミドルウェアでらくらくに扱える日が来るかも知れませんね。github.com

Schema Registry について書いていく その1: Confluent Schema Registry

Apache Avro について書き下していく記事その 2 です。本記事では Avro で表現されるデータのプログラミング言語上の表現、特に Java を想定して SpecificData と GenericData について触れていきます。Avro のデータ型とコード生成前回の記事で触れた通り、 Avro では様々なリッチなデータ型を表現できます。多くの場合一番外側のスコープでは record type を使って構造体を定義することになるかなと思います。Avro スキーマは以下のように事前に JSON 文字列を埋め込むか .avsc ファイルで保存しておくのもアリですが、実行時に動的生成することもできます。{  "name": "Hello",  "type": "record",  "fields": [    {      "name": "id",      "type": "long"    },    {      "name": "name",      "type": "string"    }  ]}ここで定義したデータ型を実際にどう扱いましょうか？例えば Protocol Buffers ではちょうど Avro で .avsc ファイルに記述するように、以下のようにおおむね .proto ファイルにメッセージ型を定義していくことになると思います。syntax = "proto3";package com.syucream.example;message Hello {  uint64 id = 1;  string name = 2;}その後典型的には protoc と各言語に対応する protoc plugin を用いることで、定義したメッセージ型に従ったコードを生成することになります。$ protoc --java_out=./ hello.proto// Generated by the protocol buffer compiler.  DO NOT EDIT!// source: hello.protopackage com.syucream.example;public final class HelloOuterClass {  private HelloOuterClass() {}  public static void registerAllExtensions(      com.google.protobuf.ExtensionRegistryLite registry) {  }  public static void registerAllExtensions(      com.google.protobuf.ExtensionRegistry registry) {    registerAllExtensions(        (com.google.protobuf.ExtensionRegistryLite) registry);  }  public interface HelloOrBuilder extends      // @@protoc_insertion_point(interface_extends:com.syucream.example.Hello)      com.google.protobuf.MessageOrBuilder {    /**     * <code>uint64 id = 1;</code>     */    long getId();    /**     * <code>string name = 2;</code>     */    java.lang.String getName();   ...つまりアプリケーションに組み込んで用いる際に事前にコード生成を求められます。Avro ではコード生成はオプションです。事前に生成したコードを用いることも、そうでない選択肢を取ることもできます。基本的なデータ型表現セット GenericDataorg.apache.avro.generic.GenericData は Avro のデータ型の Java での表現の基礎となるクラスなどが詰まったユーティリティです。GenericData 以下に具体的な型に対応したクラスが存在します。例えば record なら org.apache.avro.generic.GenericData.Record といった具合です。以下では特にこの GenericData.Record を掘り下げましょう。まずこのクラスは org.apache.avro.generic.GenericRecord interface を実装しているので、まぁ名前の通りなのですがつまり値を get したり put したりできます。一見あまり情報量が無さそうなこの interface は、結構色々な Java 製ミドルウェアで頻出します。またこの get() の戻り値は Object 型であり、実際どんな型なのか意識するのは get() を呼び出すコードを書く人の責務になります。GenericData.Record オブジェクトを作るには、 Schema オブジェクトを渡して new します。Schema オブジェクトは Schema.Parser を使って事前定義した JSON 文字列をパースして得るのもよし、動的に Schema.createRecord() などから生成してもよし、です。この GenericData.Record ですが、フィールドの具体的な値は Object[] 型のメンバとして持ち、 get/put などをする時は Schema オブジェクトの情報からフィールドのインデックスを得てアクセスします。これはちょうど、 Avro の仕様としてシリアライズした後のバイナリのレイアウトがどうなっているかがスキーマによって決定づけられる（他にレイアウト情報を持たずスキーマを信じる）のに対応しそうです。GenericData を読み書きする GenericDatumReader/GenericDatumWriterorg.apache.avro.generic.GenericDatumReader を用いることでシリアライズされた状態のバイナリから GenericData 以下の Java のオブジェクトを取り出すことができます。ジェネリクスのパラメータは、例えば record 型の値を参照するだけでいいなら前述の GenericRecord を指定するので良いでしょう。逆に Java のオブジェクトをシリアライズしたい際は org.apache.avro.generic.GenericDatumWriter を使うことができます。より具体的な使い方は公式のテストコードを見ると参考になります。github.comAvro のシリアライズ方法とバイナリレイアウトを決めているのはスキーマです。というわけでもちろん、GenericDatumReader / GenericDatumWriter を用いる際にはスキーマ情報が求められます。さて実は GenericDatumReader には二種類のスキーマ、引数名でいうと reader と writer を与えることができます。名前の通り writer は GenericDatumWriter を使ってシリアライズする側で用いられた側のスキーマ、 reader は GenericDatumReader で読み出す側のスキーマです。具体的で実用しそうなシナリオとしては、 writer が古いスキーマでシリアライズする可能性のある環境下で reader としては新しいスキーマ（古いスキーマからの後方互換性がある）に従う型のオブジェクトとして扱いたい際に二種類のスキーマを与える場合がありそうです。より安全で高速な表現セット SpecificDataさてこの GenericData 関連のツールですが、値の取り回しは Object 型ですることになるので逐一キャストしなければならず、安全な実装をできるかやキャストするコストが発生する点が気になります。悪い言い方をすれば、シリアライズ・デシリアライズの操作を含めてスキーマに違反していないことをは保証された値でしかなく、 Java のコード上は例えば record 型なら単なる Map<String, Object> 型オブジェクトと言えそうです。幸いなことに Avro では GenericData を使うのとは別に SpecificData サブクラスを使う道も存在します。org.apache.avro.specific.SpecificData は GenericData のサブクラスです。と言ってもこのクラス自体にはさほど機能は追加されていません。重要なのはこれを継承した、自動生成された schema specific なクラスです。SpecificData なクラスのコード生成最初に述べた通り Avro には事前に .java ファイルのコードを生成しておく道もあります。コード生成は avro-tools を通して行えます。試しにこの記事の冒頭に出てきた .avsc からコード生成してみます。$ java -jar ~/tools/avro-tools-1.8.2.jar compile schema hello.avsc ./Input files to compile:  hello.avsclog4j:WARN No appenders could be found for logger (AvroVelocityLogChute).log4j:WARN Please initialize the log4j system properly.log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.得られる Java のコードは以下のようになります（一部抜粋）/** * Autogenerated by Avro * * DO NOT EDIT DIRECTLY */import org.apache.avro.specific.SpecificData;import org.apache.avro.message.BinaryMessageEncoder;import org.apache.avro.message.BinaryMessageDecoder;import org.apache.avro.message.SchemaStore;@SuppressWarnings("all")@org.apache.avro.specific.AvroGeneratedpublic class Hello extends org.apache.avro.specific.SpecificRecordBase implements org.apache.avro.specific.SpecificRecord {  private static final long serialVersionUID = -8266440640401408575L;  public static final org.apache.avro.Schema SCHEMA$ = new org.apache.avro.Schema.Parser().parse("{\"type\":\"record\",\"name\":\"Hello\",\"fields\":[{\"name\":\"id\",\"type\":\"long\"},{\"name\":\"name\",\"type\":\"string\"}]}");  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  ...  @Deprecated public long id;  @Deprecated public java.lang.CharSequence name;  /**   * Default constructor.  Note that this does not initialize fields   * to their default values from the schema.  If that is desired then   * one should use <code>newBuilder()</code>.   */  public Hello() {}  ...  /**   * Gets the value of the 'id' field.   * @return The value of the 'id' field.   */  public java.lang.Long getId() {    return id;  }  /**   * Sets the value of the 'id' field.   * @param value the value to set.   */  public void setId(java.lang.Long value) {    this.id = value;  }  /**   * Gets the value of the 'name' field.   * @return The value of the 'name' field.   */  public java.lang.CharSequence getName() {    return name;  }  /**   * Sets the value of the 'name' field.   * @param value the value to set.   */  public void setName(java.lang.CharSequence value) {    this.name = value;  }  ...嬉しいことにフィールドの型に対応した getter/setter が手に入ります！GenericRecord interface のメソッドを使うよりこちらの方が安全で若干高速になるはずです。見てきた通り SpecificData 系サブクラスはコード生成する都合コンパイル時にスキーマが決まっている必要があります。またスキーマ定義が頻繁に変更され、その度にコード生成し直しまくるのもやや煩雑かと思われます。あまり変わらない・変えたくないデータ型を定義する時は SpecificData からなるクラスを生成、動的に・頻繁に変わる可能性があるデータ型は GenericData として扱うのが良いかもしれません。Java 意外の言語ではどうなる？Java の例を見てきた通り Specific なテータ表現は Generic なもののサブセットとなっています。そんな訳で多くのプログラミング言語では Generic なデータ表現はサポートされています。が、 Specific によってはサポート状況がまちまちなようです。筆者が認識した限りでは、 C++ で experimental でサポート? されていたり、 Go では gogen-avro を作っている人がいます。飽きてきたので本記事はこのあたりで終わります。あとは筆者がよくハマる、複雑なスキーマを定義してみる話やシリアライズされた後のバイナリのレイアウトの話とか別記事で書くかもしれないです。

Apache Avro について知っていることを書いていく　その2

Apache Avro になにかと縁があり、かつ普及しているテクノロジーの割に日本語の情報がそんなにない（個人の意見です、意外とあるかも）のでつらつら書いてみます。整理はされておらずシーケンシャルに要素を並べています。実装についてとくに言及がされていなければ、 Java の 1.8.2 について触れているものとします。Apache Avro はデータフォーマットとエコシステムのひとつApache Avro は Apache トップレベルプロジェクトのひとつでファイルフォーマットとその周辺エコシステムです。比較される技術として Protocol Buffers や Message Pack が挙げられると思います。Apache Avro はそれらの中でも主に Hadoop エコシステムなどビッグデータ絡みの文脈でよく登場するように思えます。以下のディレクトリ構成の通り、公式でいくつかのプログラミング言語をサポートしているようです。github.com筆者はほとんど Java のパッケージしか使わず正確な比較も行ってないのですが、おそらく Java 向けの機能がサポート厚めだと思われます。avro-tools が Java で書かれてたり avro-protobuf という Protocol Buffers との変換ライブラリが提供されていたりするので。また非公式ですが以下のような他言語向けライブラリもあったりします。github.comAvro はスキーマの表現力が強いAvro はスキーマに従いシリアライゼーションとでシリアライゼーションをするわけですが、このスキーマの表現力が割と強いです。雑に列挙すると以下の通りです。record 型(構造体)のサポートエイリアスや doc 、 namespace の宣言もできる(オプション)array 型(配列)のサポートunion 型(共用体)のサポートnull 型との union を取り、デフォルト値を null にすることで nullable な型を表現できるmap 型のサポートenum 型のサポートfixed 型という固定長バイト配列のサポート（使ったこと無いのでよくわからん）デフォルト値が設定できるlogical types を使うことで型に別の解釈をもたせることができるメジャーな使い方として long 型に timestamp-millis logical type をもたせるなどtimestamp の制度は micros も選べるこれらにより、かなりリッチなスキーマを記述することができるはずです。Avro のスキーマを記述するのがつらい表現力が高いこともあるのですが、基本的にスキーマは JSON で記述することになる上か結構冗長でかつ人間にとって読みにくい内容になりがちです。公式リポジトリに簡単な例があるのですが、簡単なものでもある程度事前知識を求められるでしょう。さらに型をネストし始めたら地獄です。筆者は特殊な訓練を繰り返すことにより最近手でスキーマを書けるようになってきた気がしますが、このスキーマの記載を同僚に求めるのは酷なものです。github.comこの問題はかなり認知されているのか、公式が IDL を提供しています。一見 Protocol Buffers を彷彿とさせる気がするシンタックスですね。avro.apache.orgまた、プログラムから動的にスキーマを記述、生成することもできます。Java であれば Schema.createRecord() して List<Schema.Field> オブジェクトを埋めて・・・といった流れで実現できます。Avro 自体の圧縮効率はそんな高くない？int, long は zigzag encoding してくれますが、 bytes, string は length + バイナリなどかなりシンプルなシリアライズをします。結果としてシリアライズされたあとのバイナリのサイズは Protocol Buffers や Message Pack と比較してそんなに潰れないと思います。（実測した訳でなく、単にこれまでの経験則程度の話です）ただ Object Container Files フォーマットを取るとブロック単位に圧縮をかけてくれたりします。Object Container Files フォーマットの便利さあなたがデータアナリストやデータサイエンティストなどのポジションで働いているなら、このフォーマットで Avro と対面することが多いかもしれません。.avro 拡張子をよく取る、 Object Container Files フォーマットに従うレイアウトを取ったファイルです。実体は well-known な Avro スキーマに従ってシリアライズされたファイルになります。そのスキーマの中にはレコードのスキーマとコーデック、フィンガープリント情報などが含まれます、ここのスキーマ情報により、ファイルを読むことで中のバイナリがどんなスキーマでシリアライズされたかわかるので動的にデシリアライザを生成して読める状態になってるわけですね！すぐれもの！このファイルフォーマットは BigQuery や Redshift でもサポートされており、 Hadoop エコシステムにあまり関わらずとも Avro のファイルをオブジェクトストレージに書き出しておけば、あとで DHW に統合して安全便利にクエリを投げられるわけですね！すぐれもの！avro-tools が開発運用に便利あまり言及されてない気がしますが、 avro-tools という Java 製のツールが便利です。事前定義した Avro のスキーマを記載した.avsc ファイルから Specific クラスを自動生成するのはもちろん、 Object Container Files フォーマットのファイルから schema を読んで吐いてくれたりレコードを json に変換して出力してくれたりします。特にレコードを json で出力してくれると、 jq などと組み合わせてフィルタしたり内容確認できたりして便利ですね。mvnrepository.com飽きてきたので本記事ではこれくらいにしておきます。気力があったり次回書きたいことがまとまってきたらまた書きます。

Apache Avro について知っていることを書いていく　その1

TL;DR2019/07/19(金)に、ヤフー株式会社様コワーキングスペースの LODGE において、「データとML周辺エンジニアリングを考える会」という勉強会の第二回目を開催しました。data-engineering.connpass.comデータエンジニアリングとサイエンス、アナリティクスにざっくり被るような少し広く曖昧なドメインで開始した勉強会です。今回は前回より少々多めで、 40 人強の参加者が参加してくれました。発表、 LT に合わせて懇親会も議論が弾み、主催のひとりとしては実現したかったことがある程度できたのではないかと考えています。つらつら発表内容せっかくなので覚えているうちに発表資料のリンク記載と超個人的な感想載せてみます。15 分枠GCPでStreamなデータパイプライン運用しはじめた by @shoe116メルカリでのログ収集のためのパイプラインの構築の話です。マイクロサービスアーキテクチャへの移行やビジネス・組織のスケールに合わせた試行錯誤の跡が伺えます。というかわたしも業務で参加してるやつです。実際上記の試行錯誤をしています。speakerdeck.com行動ログ処理基盤の構築 by @hirosassaサービスにおける行動ログの収集基盤の刷新の話です。現行システムが pull 型で基盤側がサービスの内情を知ってしまう問題を、 push 型のアーキテクチャにしたあたりが今後の投資になりうるおもしろい点なのではと思います。（基盤システムってどこまでサービスのことを知るか、責任分界をどこでするかしばしば悩ましくなりますよね）speakerdeck.comLT 枠Google Cloud ML Engineに浸かってみる by @yudeayaseGCP の ML Engine の話です。ML Engine, 便利そうではあるもののこの仕組みに特化してしまうのは良いのか？などと考えさせられました。cloud.google.com（資料アップロードなし？あとで調べるPoC案件が多すぎてつらいので、パイプラインを使いまわすツールを入れた。 by @mori_kaz0429繰り返し発生する PoC 案件で、似たようなクエリを投げたりすることが多い処理を共通化、再利用可能にする話です。最後の方には Apache Airflow などワークフローエンジンを今後使ってみたい話も。（資料アップロードなし？あとで調べるCloud Composer & Cloud Dataflow によるバッチETLの再構築 by @yuzutas0Cloud Composer (Apache Airflow のマネージドサービス) を使って壊れかけのデータ同期の仕組みを立て直す話です。データエンジニアとデータアナリスト、両方に対してヒアリングをかけつつ現状を鑑みて良いバランスのところを攻めるというマネジメントに近い側面もあれば、 Cloud Dataflow によるクレンジング処理に触れたりする話もあり盛りだくさんでした。speakerdeck.comDigdagでETL処理をする by @nakano_shota今度は Digdag でワークフローを組んだ話です。s3_touch というオペレーターを開発して、 s3_wait と組み合わせてプロジェクト間依存関係も対応できるようにしていて良い。あまり深く触れられなかったけどリトライ処理や冪等性担保大事ですよね。もっとお話聞いてみたい気がします。speakerdeck.comComet.ml で AutoML ライブラリ開発（仮） by @Y_oHr_NComet.ml 、初めて知ったのですがかなり良さそう！codecov でカバレッジを可視化するのと同じようにモデルの可視化をできるのは好感触！speakerdeck.comデータ活用の際にハマってしまったログ・データスキーマ設計 by @yu-ya4この手の苦労話、これこそこういう勉強会で話し合いたかったことな気がします。テーブルの日付が何の時間を表すか問題、スキーマ更新にどう立ち向かうか、 STRING 型フィールドに JSON 突っ込むのどうなんだ話、 null の扱いと結構あるある話な気がするが・・・。二番目の話題は個人的にも刺さるものがありました。簡易にアプリケーションからログを出力して、読み出す時に苦労するスキーマオンリードの戦略自体は間違ってはいないはずだし・・・。触れられていなかった別の点として、 BigQuery はカラムナでデータを持ってくれているはずなのですが、 JSON を突っ込んで読む時にパースするではパフォーマンスが落ちる（課金が増える？）かもしれないなと思いました。speakerdeck.com今後に向けて幸いなことに参加者の方々からもそれなりに好評を得られたようだし、自分としても知見を得たい気持ちもあるため、主催メンバーで話し合いつつ第三回を企画していきたいと考えています。ジャストアイデアですが、初心者枠？というかこれからデータ基盤を作っていこうとする人たちが発表しやすい枠を設けるとかもあるとイベントの雰囲気変わるかなとか。その時が来たらまたアナウンスしますので、ご興味ある方々いらっしゃいましたらぜひぜひ！！

「データとML周辺エンジニアリングを考える会」という勉強会の第二回を開催しました

こちらで紹介した、僕が主催するサークルで技術書典5で配布した同人誌の原稿データを公開しました。syucream.hatenablog.jpリポジトリはこちらになります。github.com前回と同様、 Re:VIEW を使って記述しています。epub / pdf ファイルが欲しい方はいい感じにビルドしてください。もし多少でも気に入った方がいらっしゃれば、 Kindle 版を購入していただけると幸いです！僕のジュース代の足しくらいにはなります。www.amazon.co.jp

技術書典5で配布した同人誌の原稿データを GitHub で公開しました

この記事は 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 をアタッチ・デタッチしたりスナップショットを取ったりする機能のためのインタフェースを提供します。CSI は Kubernetes とは独立したプロジェクトで進行しております。github.comまた Kubernetes のプロジェクト以下で、 Kubernetes から SP が提供する CSI プラグインへ通信するための CSIDriver と関連実装を以下プロジェクトで進行しています。github.comKubertenes としては CSI は 1.9 で Alpha 、 1.10 で Beta サポート対象になっていますまた Kubernetes での CSI 利用については他に既に試されている方もいるようです。こちらの記事は詳細に踏み込んだ構成説明などもされており、オススメできる内容になっています。qiita.comCSI の仕様CSI のインタフェース仕様は Protocol Buffer で定義されており、以下リポジトリで管理されています。またこのリポジトリ内の lib/go/ ディレクトリには .proto ファイルの定義に従ったライブラリの Go 実装が配置されています。github.comCSI のプラグインは Controller plugin, Node plugin の二種類が想定されております。また CO とこれら CSI プラグイン間は gRPC で通信することが想定されています。CSI のサービスCSI のサービスとして以下三種類が想定されています。構成によっては実装しなくても良いサービスやメソッドがありますが、少なくとも Node Service の NodePublishVolume, NodeUnpublishVolume は実装する必要があります。（でないと Node から Volume を参照できないはず）Identity ServiceCO から Plugin のケーパビリティ (後述) やヘルスチェック、メタデータ参照を可能にするサービスController ServiceNode をまたいで Volume の構成を管理するためのサービスVolume のスナップショット操作もサポートするNode Service各 Node から Volume の操作を可能にするためのサービスCSI における Volume の状態遷移CSI で Node から Volume を利用されるまでに、 Volume は基本的に以下のような状態遷移をしていきます。幾つかの状態は、プラグインが示す後述の CSI ケーパビリティによって存在しなかったりします。   CreateVolume +------------+ DeleteVolume +------------->|  CREATED   +--------------+ |              +---+----+---+              | |       Controller |    | Controller       v+++         Publish |    | Unpublish       +++|X|          Volume |    | Volume          | |+-+             +---v----+---+             +-+                | NODE_READY |                +---+----^---+               Node |    | Node              Stage |    | Unstage             Volume |    | Volume                +---v----+---+                |  VOL_READY |                +------------+               Node |    | Node            Publish |    | Unpublish             Volume |    | Volume                +---v----+---+                | PUBLISHED  |                +------------+ref. https://github.com/container-storage-interface/spec/blob/master/spec.md#volume-lifecycleCSI のケーパビリティCSI プラグインでどのような操作をサポートするかの情報です。CSI の仕様としては以下 4 種類のケーパビリティをサポートします。PluginCapabilityCSI プラグイン全体でサポートする機能Controller Service を提供するか、オンラインボリューム拡張をサポートするかなどの情報を含むCO は GetPluginCapabilities メソッドで取得可能VolumeCapabilityVolume のファイルシステムのタイプやアクセス制御（リードオンリーなのかなど）、容量などの情報を含むCO は CreateVolume, ControllerPublishVolume などのメソッドで指定や値の検証が可能ControllerServiceCapabilityCreate/Delete , Publish/Unpublish などの操作をサポートするかの情報を含むCO は ControllerGetCapabilities メソッドで取得可能NodeServiceCapabilityStage/Unstage などの操作をサポートするかの情報を含むCO は NodeGetCapabilities メソッドで取得可能CSI の利用用途CSI プラグインとしてはすでに、 NFS や iSCSI などの公式のサンプルプラグインを含め、 AWS や GCP のストレージサービスの利用を可能とするプラグインが存在します。以下の公式ドキュメントに既に存在する CSI プラグインに関する記述があります。kubernetes-csi.github.io簡単な CSI Plugin の実装を追ってみる以上だけだと CSI プラグインの動作が把握し難いので、 kubernetes-csi の drivers リポジトリにある HostPath plugin の動作を追ってみます。このプラグインはリポジトリに kubernetes への deploy 用 yaml ファイルも同梱されており動作を追うのに便利です。HostPath plugin では CSI の Identity, Controller, Node 三種類の gRPC サービスを提供します。その実装は github.com/kubernetes-csi/drivers/tree/master/pkg/hostpath に存在します。Identity Server は特に特殊な実装をしていません。github.com/kubernetes-csi/drivers/blob/master/pkg/csi-common に存在する、他の Driver と共通のデフォルトメソッド実装をそのまま使用しています。Controller Server では CreateVolume, DeleteVolume , CreateSnapshot, DeleteSnapshot, ListSnapshots を実装します。CreateVolume, DeleteVolume では複雑なことをしておらず、 UUID 付きの名前のディレクトリを掘って Volume に見立て、 map で Volume の管理を行います。CreateSnapshot, DeleteSnapshot はそれに似て、 Volume のディレクトリを tar czf で固めて同じく UUID 付きのファイルに保存・管理します。Node Server では NodePublishVolume, NodeUnpublishVolume, NodeStageVolume , NodeUnstageVolume を実装します。NodePublishVolume, NodeUnpublishVolume は作成された Volume のディレクトリを k8s.io/kubernetes/pkg/util/mount パッケージを介して mount/unmount します。NodeStageVolume , NodeUnstageVolume は単にリクエストパラメータ中の Volume や ターゲットパスが空でないことをチェックしているだけになります。HostPath プラグインでは他に複雑なチェックをする必要が無いためこうなっているのではと思われます。kubernetes 上で想定される構成は以下の通りになっているようです。Controller Server のメソッドの参照CreateVolume など Volume の作成・削除は https://github.com/kubernetes-csi/external-provisioner コンテナを利用ControllerPublishVolume など Volume の Publish 操作は https://github.com/kubernetes-csi/external-attacher を利用CreateSnapshot などスナップショットの操作は https://github.com/kubernetes-csi/external-snapshotter を利用Node Server のメソッド参照https://github.com/kubernetes-csi/driver-registrar を使って CSIDriver を kubelet から参照可能にするkubelet から CSIDriver をプラグインにという格好で読み出し参照するロジックは Kubernetes 本体リポジトリの kubelet と関連パッケージに存在おわりに以上、 CSI とその Kubernetes へのインテグレーションに関する記事でした。CSI は可搬性を担保しつつ Kubernetes での利用を重要視されて作られているようですが、 CSI の仕様含めエコシステムもまだ枯れているとは言えず、機能も多くはありません。Kubernetes 用の単なるサンプルとはいえ HostPath プラグインで tar コマンドを実行してスナップショットを作成したりなど、もう少し抽象化されてほしい箇所もまだ存在します。しかしながら個人的には Kubernetes での柔軟なストレージ利用には、以前の記事で挙げた通りまだまだ課題があると思っており、今後の発展を期待したいと考えています。syucream.hatenablog.jp

Kubernetes と CSI(Container Storage Interface) について

本題の通りの気持ちがあったのですが、結論としては手軽にできる良い方法は無いようでした。備忘録的に挑戦した事を記録しておきます。背景: FUSE 利用のモチベーション言うまでもなくファイル I/O はシステム開発においてよく使われる機構であり、多くのプログラミング言語において標準ライブラリまたはそれに類するライブラリでファイル I/O をサポートしていると思われます。さて Kubernetes 上でマイクロサービスを実装していく事が多々あるこのご時世、各マイクロサービスで実装言語非依存で使えるデータの読み書きのロジックがあると、例えば何らかの設定ファイルの動的受け渡しやロギングにおいて便利な可能性があります。これに似た課題を抱えて解決に向かったプロダクトとして Envoy Proxy があるかと思われます。これは元々ネットワーキングやトレーシングの課題などを各言語ごとのライブラリで対応していたもののつらくなり、 HTTP や gRPC を解釈するプロキシを導入することで緩和に成功しています。前述の通りファイル I/O は HTTP や gRPC をしゃべるより更にリーズナブルな共通プロトコルであると考えられもしそうです。さらに FUSE を使えばファイルシステムとしてインタフェースを提供して、かつ裏側で複雑なロジックを動かすこともできるように考えられます。そんなわけで、 Kubernetes 上で動作するコンテナからいい感じに FUSE で実装したファイルシステムをマウントして利用できると良いかもと着想した次第です。FUSE 利用の限界同じような思考をしたり、あるいは既存 FUSE 資産を利用したい人たちが多々居たようで、 Kubernetes 公式リポジトリの Issue でも議論がされていたりします。github.com残念ながらこの 2015 年に open した issue は 2018 年も終わりを迎える今日においても close されていません。どういう点がネックになるかというと/dev/fuse を open するのに特権が必要mount, umount するのに SYS_ADMIN ケーパビリティが必要が挙げられ、一応利用できなくは無いものの利用条件を満たすため現状は privileged mode でコンテナを動かす羽目になり、やや安全面でリスクがあるように思えます。FUSE 利用パターンいくつか前述の Issue の中で幾つかのアイデアも提示されています。少しこれらを実際に試してみることにしました。多少このリスクを緩和するため、大きく分けて以下の方針がありそうです。コンテナ外でなんとかするパターン特権を持つコンテナをアプリケーションを動作させるコンテナと分離するパターン前者は場合によっては可搬性を損なうか導入が非常に困難になる恐れがあり、また後者であればコンテナ内の世界で完結させることができそうです。従ってまずは後者のアイデアを試してみます。以下に検証用に用意した Dockerfile や設定ファイルを配置しました。FUSE でマウントするのは libfuse に含まれる、ファイルを read すると "Hello, World!" を返す hello.c を利用しておきます。github.comこちらのリポジトリでは initContainers で mount するのと、 postStart , preStop でサイドカーコンテナで mount/umount する案を試してみました。が、結局マウント先を参照するアプリケーションコンテナからはマウントした先は参照できなくなります。結局この例だと特権を渡さざるを得ませんでした。次の一手のアイデア今回特権を要求されたのが、コンテナ内から /dev/fuse が open できない点なので、この点を何とかできれば 多少課題は緩和されるかもです。Kubernetes は Device Plugin という機構を最近サポートしているようで、これで何とかできる可能性があるような全く無いような気がしています。また Kubernetes v1.10 からベータになったというストレージ接続インタフェース CSI は将来も見据えてこの問題に取り組むのに、もしかしたら良い機構かもしれません。いずれにせよ Kubernetes 自体の調査をほとんどやっていないので次の一手はこれら周辺技術の調査からかと考えております。

Kubernetes 上で動作するコンテナから安全に FUSE を利用したかった

タイトルのとおりです。何やかんやあり ISUCON8 の予選を無事突破した後に 10/20(土) LINE さんのオフィスにて本戦に参加して、最終成績 3 位に収まりました。3 位だと特に表彰されるわけでもなく気持ちのみなのですが。チーム構成と役割分担について職場のよしみで cubicdaiya さん、  catatsuy さんと何らか SRE チームらしき雰囲気を醸し出しながら参戦しました。大枠としては以下の役割分担を組んでいました。インフラ担当cubicdaiyaアプリ担当catatsuysyucream全体チーム構成やツール・環境構築お膳立ては catatsuy さんがいい感じにやってくれていました。予選について本記事執筆にあたり予選実施日と期間が空いて、ほぼすべての記憶を損失しました。様子はたぶん catatsuy さんの以下記事にある気がします。medium.com本戦についてだいたい出題された課題の要点は以下記事で説明されています。isucon.net3 位に入賞できた決めては突出したコレという点は無く、チームでそれぞれ貢献できた、バランス的には良い塩梅なのではと感じました。具体的なタイムラインとしては覚えている限り以下のとおりです。前半: 好調な滑り出しとりあえず各々初期準備をする自分はここでは DB スキーマを取り出して共有したり WebUI 調べたりcatatsuy さんが早期にログ分析APIの叩き方問題に気づく着想としてはrate limitとかより重要なパスでI/Oしていそうなことがやばそう11 時台に議論して、ハマりそうだから手を打とうと結論づけて catatsuy さんが着手しだすsyucream が LIMIT 1 問題に気づく最初はサブクエリ書く感じで改善したが LIMIT 1 するのと課題的に差分がそれほどなかったここで一時的に 5000 点ほどスコアを叩き出しトップに躍り出る時間軸が入れ替わるが、この改善の実施直前に cubicdaiya さんが slow query を出してくれていてプロファイルの裏付けもした上で実施したcubicdaiya さんがインフラ周り、特に nginx 周辺のチューニングを徐々にする冗長そうなコンテナ化をやめる静的ファイルを nginx で配信中盤: 次ステップへの到達との葛藤会場提供でランチとして弁当が出るAbemaTV のニュースで鯖の漁獲量が減って値段が若干上がった話を思い出し、僕は思わず鯖味噌煮弁当を確保catatsuy さんのログの集約送信が動き出すsend_bulk API の利用がうまくいかず、時間ももったいないのでバッファリングして send するだけにとどめたりこの瞬間はスコアに響かなかったが、後々ボディブローのように効いてきた感じがあるsyucream が地味に無駄そうな user table のレコードロックを外すslow query ではあったが、全くスコアに響かなかったcubicdaiya さんがそろそろいいでしょと良い SNS share 機能を有効化するsyucream が雑にロウソク足チャートのオンメモリキャッシュを入れるマージした後に、一度キャッシュをすると別タイミングに対してのクエリにもキャッシュヒットしてしまうバグに気づくが、ベンチマーカが文句を言わなかった！一瞬チームで相談して、問題が出てないなら後で考えようと結論づけるcubicdaiya さんが複数台構成を考え始める特に異論無く、 1: DB, 2: App, 1: nginx という意思決定が即なされる後半: 着眼点は悪くなかったがもう一歩だったかcatatsuy & syucream で orders & trade の課題について考え出すかなり真面目に巨大トランザクションを引き剥がすとか検討したが、いまいち鳴かず飛ばずその裏で cubicdaiya さんが App サーバを 2 台構成にしていたこのあたり？でスコアが 10000 近くに到達catatsuy さんがミクロな最適化したり、 syucream が銀行 API アクセスを並列化したり N+1 を無くそうとして爆死したりその裏で cubicdaiya さんが 4 台フルに使い切る構成への移行を追えてチューニングに入ったりDB の負荷をさげたくて ORDER BY を使うクエリを Go のアプリレベルに移植して時間がたりなかったり一部さばけない負荷に対して cubicdaiya さんが async sleep 入れたりsyucream はこれが大きな差別化ポイントだった気がしているそうこうしている間に 17:50 頃になって収束させて終了'もう一歩' に対する所感着眼点は非常に良くて、 PARTITION に対する疑惑や POST /orders 、 RunTrade() 最適化は課題に感じていて一部取り組んでいましたあらかじめ配布された spec を読み込んだり、外部 API に対して向ける疑惑がもっとあっても良かったかも結論: ISUCON はいいぞ今回の出題の外部 API が絡む話は個人的によく練られていて、個人的に非常に好ましい話でした。なぜならこういう外部APIとその挙動の差異は現実問題に起こりうりそうな話だからです。そういう観点から言うと、学生チームが優勝したという展開はとても興味深いようにも思えます。個人的課題として、自分が当日見ていた箇所で見どころは誤っていないけど一歩足りなかったことが挙げられ、狂おしいほど悔しいです。もし次回参加して同じメンバーでチームを組むのなら、 catatsuy さんが優勝するのに並々ならぬ熱意を抱いているのでたぶん僕らが優勝するでしょう。

ISUCON8 に参加して最終成績が本戦3位だった

表題の通りです。github.comcgo を使って POSIX message queue の基本的な操作、 open/close と send/receive とその他細々とした機能を実装しています。とは言っても、それほど複雑なことはしておらず、 POSIX の関数呼び出しを愚直に Go の func にラップしているだけなのですけどね。なぜやったのか入門 Kubernetes などを読むと、 Pod 内のコンテナ同士では SysV / POSIX の IPC namespace を共有している記述があります。www.oreilly.co.jpPod 内の別コンテナへの通信となると、 sidecar パターンで Envoy を動かすようなネットワーキング用プロキシを介するのに利用したり fluentd などのロギングエージェントにログを送ったり、お決まりのパターンがあると思います。そういった際に低コストで非言語依存なプロトコルが欲しくなることが多々あるように考えられます。POSIX message queue は POSIX としての仕様も存在し、低コストな IPC 手段のひとつです。これを選択肢のひとつとして用意しておくことは発生する課題に柔軟に対応するのに重要であると考えます。手段は他にもあるし、同様の機能であれば SySV message queue やいっそ AMQP などをしゃべっても良い気もするのですが、手段を増やす意味でも今回のライブラリを開発してみた次第です。動作例sender / receiver の通信例シンプルなsender と receiver であれば以下のコードで実装してやり取りできます。sender.gopackage mainimport (    "fmt"    "log"    "time"    "github.com/syucream/posix_mq/src/posix_mq")const maxTickNum = 10func main() {    oflag := posix_mq.O_WRONLY | posix_mq.O_CREAT    mq, err := posix_mq.NewMessageQueue("/posix_mq_example", oflag, 0666, nil)    if err != nil {        log.Fatal(err)    }    defer mq.Close()    count := 0    for {        count++        mq.Send([]byte(fmt.Sprintf("Hello, World : %d\n", count)), 0)        fmt.Println("Sent a new message")        if count >= maxTickNum {            break        }        time.Sleep(1 * time.Second)    }}receiver.gopackage mainimport (    "fmt"    "log"    "github.com/syucream/posix_mq/src/posix_mq")const maxTickNum = 10func main() {    oflag := posix_mq.O_RDONLY    mq, err := posix_mq.NewMessageQueue("/posix_mq_example", oflag, 0666, nil)    if err != nil {        log.Fatal(err)    }    defer mq.Close()    fmt.Println("Start receiving messages")    count := 0    for {        count++        msg, _, err := mq.Receive()        if err != nil {            log.Fatal(err)        }        fmt.Printf(string(msg))        if count >= maxTickNum {            break        }    }}Kubernetes の同一 Pod 上 container 通信例折角なので上記の sender / receiver を Kubernetes の Pod に押し込んで通信させてみます。あらかじめてきとうに sender / receiver 用の Docker イメージを作っておいてください。Pod の定義なのですが、愚直に container の設定を羅列していくだけです。IPC namespace は勝手に共有されるのでそれに関する設定や準備は必要ありません。apiVersion: v1kind: Podmetadata:  name: posixmq-podspec:  containers:    - name: posixmq-sender      image: "posix_mq_sender"      imagePullPolicy: IfNotPresent    - name: posixmq-receiver      image: "posix_mq_receiver"      imagePullPolicy: IfNotPresent  restartPolicy: NeverPod の動作確認をさくっとしてみましょう。$ kubectl apply -f example/kubernetes/pod-posixmq.yamlpod "posixmq-pod" created...$ kubectl logs posixmq-pod -c posixmq-sendergo run example/exec/sender.goSent a new messageSent a new messageSent a new messageSent a new messageSent a new messageSent a new messageSent a new messageSent a new messageSent a new messageSent a new message$ kubectl logs posixmq-pod -c posixmq-receivergo run example/exec/receiver.goStart receiving messagesHello, World : 1Hello, World : 2Hello, World : 3Hello, World : 4Hello, World : 5Hello, World : 6Hello, World : 7Hello, World : 8Hello, World : 9Hello, World : 10この出力結果を見るに、 sender の送ったメッセージがちゃんと receiver に届いていそうです！余談POSIX の機能となると可搬性を期待してしまいますが、 POSIX message queue は darwin や windows では実装されていなかったりと意外に可搬性に欠けます。対して SysV の message queue はこれに比べて可搬性が高く、より多くの環境でサポートされています。（このあたりは Linuxプログラミングインタフェース にも記述されていますね！）www.oreilly.co.jpとは言っても本記事で書くようにあらかじめ環境が定められている Kubernetes クラスタ上で動かす場合は、それほど気にすることでも無いのかもしれません。また、 SysV message queue の Go ラッパーライブラリは Shopify により実装されているのでこれを試すのもアリかもです。github.comちなみに少し前のベンチマーク内容ですが、 POSIX message queue は IPC の手段として結構高パフォーマンスであるような調査結果もあります。www.programering.com

syucream

Ubie における、小さく泥臭くはじめる開発生産性改善

Django のプロジェクトのテストを並列実行してとりあえず2倍高速にした

共用のQA環境の利用状況を Notion でノーコードで可視化する

Sentry と上手く付き合ってエラー監視を改善しよう

組織を考慮してアーキテクチャとシステム運用を改善する

症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動

自社のエンジニアとラフに話せるSlackワークスペースをクローズした

GitHub Actions と GitHub Packages を使って、継続的に社内向け gem をリリースする

育休復帰後 3 ヶ月を振り返って、仕事とプライベートの両立ハードパーツ

ソフトウェアエンジニア子育てログ (3 ヶ月 ~ 4 ヶ月)

ソフトウェアエンジニア子育てログ (2 ヶ月 ~ 3 ヶ月)

ソフトウェアエンジニア子育てログ (0 ヶ月 ~ 2 ヶ月)

ユビーに転職して半年、慣れない技術スタックでも何とかやっていけている

2021年Ubie Discoveryエンジニア入社エントリまとめてみた

転職しました: メルペイ -> Ubie ~クセつよ組織を求めて~

技術書典9で「Apache Parquet ではじめる快適データ分析」を出します

Data Mesh の記事を読んだ

Avro と BigQuery の load とうまく付き合いたい

Cloud Dataflow の FlexTemplate は何者か

Schema Registry について書いていく: Confluent Schema Registry の Protocol Buffers & JSON Schema サポート

protobuf のシリアライズ済みバイナリを無理やり読む

原則 WFH 勤務が開始して二ヶ月が経過した

BigQuery SQL UDF の挙動を色々確認する

Apache Parquet の Logical Types に関するメモ

Schema Registry について書いていくその1: Confluent Schema Registry

Apache Avro について知っていることを書いていく　その2

Apache Avro について知っていることを書いていく　その1

「データとML周辺エンジニアリングを考える会」という勉強会の第二回を開催しました

技術書典5で配布した同人誌の原稿データを GitHub で公開しました

Kubernetes と CSI(Container Storage Interface) について

Kubernetes 上で動作するコンテナから安全に FUSE を利用したかった

ISUCON8 に参加して最終成績が本戦3位だった

Ubie における、小さく泥臭くはじめる開発生産性改善

Django のプロジェクトのテストを並列実行してとりあえず2倍高速にした

共用のQA環境の利用状況を Notion でノーコードで可視化する

Sentry と上手く付き合ってエラー監視を改善しよう

組織を考慮してアーキテクチャとシステム運用を改善する

症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動

自社のエンジニアとラフに話せるSlackワークスペースをクローズした

GitHub Actions と GitHub Packages を使って、継続的に社内向け gem をリリースする

育休復帰後 3 ヶ月を振り返って、仕事とプライベートの両立ハードパーツ

ソフトウェアエンジニア子育てログ (3 ヶ月 ~ 4 ヶ月)

ソフトウェアエンジニア子育てログ (2 ヶ月 ~ 3 ヶ月)

ソフトウェアエンジニア子育てログ (0 ヶ月 ~ 2 ヶ月)

ユビーに転職して半年、慣れない技術スタックでも何とかやっていけている

2021年Ubie Discoveryエンジニア入社エントリまとめてみた

転職しました: メルペイ -> Ubie ~クセつよ組織を求めて~

技術書典9で「Apache Parquet ではじめる快適 データ分析」を出します

Data Mesh の記事を読んだ

Avro と BigQuery の load とうまく付き合いたい

Cloud Dataflow の FlexTemplate は何者か

Schema Registry について書いていく: Confluent Schema Registry の Protocol Buffers & JSON Schema サポート

protobuf のシリアライズ済みバイナリを無理やり読む

原則 WFH 勤務が開始して二ヶ月が経過した

BigQuery SQL UDF の挙動を色々確認する

Apache Parquet の Logical Types に関するメモ

Schema Registry について書いていく その1: Confluent Schema Registry

Apache Avro について知っていることを書いていく その2

Apache Avro について知っていることを書いていく その1

「データとML周辺エンジニアリングを考える会」という勉強会の第二回を開催しました

技術書典5で配布した同人誌の原稿データを GitHub で公開しました

Kubernetes と CSI(Container Storage Interface) について

Kubernetes 上で動作するコンテナから安全に FUSE を利用したかった

ISUCON8 に参加して最終成績が本戦3位だった

技術書典9で「Apache Parquet ではじめる快適データ分析」を出します

Schema Registry について書いていくその1: Confluent Schema Registry

Apache Avro について知っていることを書いていく　その2

Apache Avro について知っていることを書いていく　その1