データチームの立ち上げ1年間で行ったこと - Pepabo Tech Portal
データ基盤チームの方から来ました、 @udzura です。 私の所属するGMOペパボのデータ基盤チームは、「Bigfoot」と名付けられたデータ基盤の開発・運用を行いつつ、全社のデータ駆動化を推進していく組織です。 これは2021年の資料になりますが、 @tosh2230 によるデータ基盤チームの立ち上げについての資料もありますので併せてご覧ください。このテックブログでもいくつかデータ基盤に関する記事があります。 さて、このチームは、2021年から発足した新しい組織です。なおかつ、立ち上がりの始めから全てをオンラインで行ってきた、リモートネイティブなチームでもあります。 この記事では、そんなデータ基盤チームをどのように整えていったか振り返ろうと思います。その過程で、実践したチーム開発のプラクティスを紹介します。 〜2020年のデータチームについて 2021年からの取り組み 新規ジョインメン
【Ruby】LinuxとRubyとCoW - 地方エンジニアの学習日記
hiboma.hatenadiary.jp こちらのアンサー記事を書いてみますw なぜ CoW の話が出てきたのか なぜCoWを気にしたのかを話すとまず社内で動かしているAPIサーバがメモリ利用過多となってアラートがなったのが話のスタートでした。サービス自体はUnicornを使って動いています。 メモリ利用過多となったときに調べる手法は言語ごとに様々ですが私はRubyの経験がほぼなくプロファイラなども使ったことがありません。この状況でできることは/procを見るくらいしかなかったので/proc/$pid/smapsを見始めました。そこで始めたのがメモリ共有率の計算でした。 以下のツールを書いてUnicornの親子プロセスのメモリ共有率を確認するとなんと40~60%程度となっていて「え！？」ってなったのが始まりでした。プロセスの生存期間が長いのかと思ったのですが起動時間も出すと数分前に起動し
生産性を可視化したい！ / SUZURI's four keys
@Pepabo Tech Conference #15 - ECプラットフォームSUZURIの開発の裏側 https://pepabo.connpass.com/event/215058/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大名エンジニアカレッジ
