ZOZO開発組織の2021年の振り返りと現状
株式会社ZOZO 技術本部 本部長の @sonots です。この記事は ZOZOのAdvent Calendar 2021のカレンダー1の最終回（25日目）です。 2021年度、ZOZOにとっても、私にとっても大きな変化が2つありました。1つ目が2021年3月に前CTOの今村が退任し、私が全社技術戦略を策定する役割とZOZOTOWNリプレイスプロジェクト責任者を引き継いだこと、2つ目が2021年10月にZOZOとZOZOテクノロジーズの組織が再編され、私も含む開発部門がZOZOに併合されたことです。 この記事ではその変化の中で私と組織がこの一年取り組んできたものをいくつか取り上げたいと思います。 全社技術戦略策定 2021年4月にCTO的な役割を引き継いで、個人的に一番変わったのは経営陣（当時はZOZOテクノロジーズ）との対話が増えたことだと思います。私の考えているCTOの役割と、経営陣の
書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
kubernetes で deployment リソースに変更を加えずに rolling update させる - Qiita
k8s で deployment resource に変更を加えずに pod を立ち上げ直したいことは稀によくある。 例えば secret に変更を加えた場合それだけでは pod に変更が反映されないので rolling update させたくなる。 4年ぐらい前から戦っていたらしいがどうやら決着がついて v1.15 から kubectl にそのための機能である kubectl rollout restart が入るようだ > https://github.com/kubernetes/kubernetes/issues/13488
Digdagのserverモードで環境毎に設定値を変える６つの方法 - Qiita
production や development といった環境によってホスト名が違ったりする場合にどう切り替えるか。 1. digdag start の --param オプションで指定する $ digdag start —-param environment=development --param endpoint=http://localhost:5432 ... 利点 実行ごとにパラメータを変えられるので柔軟 欠点 必須なパラメータがあるような場合に Web UI から RUN ボタンを押しても動かなくなる(パラメータ未指定の digdag start と同じ) 実行のたびにパラメータを１つずつ渡すのは面倒? 2. digdag start の --param-file オプションで指定する
digdag secrets を楽して環境変数にマップしたい - Qiita
out: type: bigquery auth_method: json_key json_keyfile: content: ${env.secret_gcp_credential} +task1: _env: secret_gcp_credential: ${secret:gcp.credential} secret_aws_access_key_id: ${secret:aws.access_key_id} secret_aws_secret_access_key: ${secret:aws.secret_access_key} sh>: embulk run embulk.yml.liquid +task1: _env: secret_gcp_credential: ${secret:gcp.credential} secret_aws_access_key_id: ${secr
S3バケットへのアクセスを特定IAMユーザにだけ許可して他は弾く - Qiita
S3バケットへのアクセスを特定IAMユーザにだけ許可したい 課題 単純に考えると、バケットポリシーを次のようにすれば、s3-audit ユーザだけがアクセスできる xxxx-audit バケットが作れそうである。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::xxxx:user/s3-audit" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::xxxx-audit", "arn:aws:s3:::xxxx-audit/*" ] } ] } しかしコレだけだと、実は PowerUser ロールなど S3 へのアクセスポリシーがついている IAM ユーザなら誰でもアクセスすることができてしまう
OSS版 drone.io でコンテナの中に入ってデバグする方法 - Qiita
やりたいこと: 手元ではテストが通るのに、drone ではテストが通らないとなって、試すために一からCIを回す、となるといくら時間があっても足りないので、drone.io がやってるのと同等の操作を行って、直接コンテナに入ってデバグしたい。 .drone.yml これを再現したいとする image: "bradrydzewski/ruby:2.0.0" env: - RAILS_ENV=test git: depth: 1 script: - bundle install - bundle exec rake db:create db:migrate - bundle exec rspec services: - mysql - redis # docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE bradrydzewski/
Fluentd のベンチマークテストに使える dummer (旧称: dummy_log_generator) - Qiita [キータ]
id:0422 time:[2013-11-19 02:34:58] level:INFO method:POST uri:/api/v1/textdata reqtime:3.9726677258569842 foobar:LFK6XV1N id:0423 time:[2013-11-19 02:34:58] level:DEBUG method:GET uri:/api/v1/people reqtime:0.49912949125272277 foobar:DcOYrONH id:0424 time:[2013-11-19 02:34:58] level:WARN method:POST uri:/api/v1/textdata reqtime:2.930590441869852 foobar:XEZ5bQsh 設定パラメータ ちょっと長くなるので読み飛ばしてもらっても良いのですが、
![Fluentd のベンチマークテストに使える dummer (旧称: dummy_log_generator) - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/037651b50805e52e87a282aba9f58b9909886afd/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-f625e957b80c4bd8dd47b724be996090.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9Rmx1ZW50ZCUyMCVFMyU4MSVBRSVFMyU4MyU5OSVFMyU4MyVCMyVFMyU4MyU4MSVFMyU4MyU5RSVFMyU4MyVCQyVFMyU4MiVBRiVFMyU4MyU4NiVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MSVBQiVFNCVCRCVCRiVFMyU4MSU4OCVFMyU4MiU4QiUyMGR1bW1lciUyMCUyOCVFNiU5NyVBNyVFNyVBNyVCMCUyMGR1bW15X2xvZ19nZW5lcmF0b3IlMjkmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ21pZGRsZSZzPTY3YjVlMjc3MTc4Nzc0ZmZiNGZhZWY4MWVmMTRhYjA0%26mark-x%3D142%26mark-y%3D151%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwc29ub3RzJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1jYTQ1Y2Y4NGNkODNjN2E1YmFkYjE4MTE2MmZlNzFjMQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D31c364f2bd98c5c6d048534777344ec2)
Fluentd v0.12 ラベル機能の使い方とプラグインの改修方法 - Qiita
Fluentd v0.12 には Fluentd v0.12 is Released で言及されているように、「ラベル」という機能が追加されています。本記事ではラベル機能の使い方、またラベル機能に対応するためにプラグインを改修する方法について解説します。 概説 このラベルという機能は、「内部ルーティングするのに add_tag_prefix したり remove_tag_prefix したり、タグ設計するのめんどくさい！！」という声にお答えして追加されたものです。 ラベル機能を使う事によって、タグを改変することなく、内部ルーティングすることができるようになります。 ラベル機能の導入によって、以下のような利点が生まれていると思います。 タグをいじることが(ほとんど)なくなったので、オリジナルのタグ情報を保てるようになった。 Fluentd 本体がサポートする機能なので、プラグイン作者が個別に
Ruby でラインメモリプロファイラ - Qiita
プロファイラ好きなモニタの前の皆さんこんにちは。@sonots です。この記事では、Ruby コードのどの行がどのぐらいメモリを消費しているか調べる方法を紹介します。 オブジェクトの数を数える Ruby には ObjectSpace というオブジェクトの情報を集めたり操作したりする module があります。 このモジュールの each_object メソッドを使用すると、RubyVM 上の全てのオブジェクトを取り出すことができます。 このメソッドを使って、以下のようなコードを書くと、実行した地点で、RubyVM 中にどのクラスのオブジェクトが何個存在しているのかカウントできたりするわけです。興味深いですね! ObjectSpace.each_object.inject(Hash.new 0) {|h,o| h[o.class]+=1; h } #=> {Class=>241, Strin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
digdag の rb オペレータで bundle exec を使う３つの方法 - Qiita
digdag の .dig ファイル向け vim 設定 - Qiita
digdag タスクの docker 実行について - Qiita
embulk-filter-calcite vs embulk-filter-column|row の速度比較 - Qiita
OSS版 drone.io 用の docker イメージをビルドする - Qiita