はじめに Data Strategyチーム（以下、DSチーム）でDWHやBIツールの運用をしている@shota.imazekiと不正検知やAWS基盤運用をしている@tawamuraです。 Aurora MySQL v2（MySQL5.7互換）が2024/10/31に標準サポート終了となるため、DSチームでは2024年6月にAurora MySQL v3（MySQL8.0互換）へのアップグレードを実施しました。 その際に得られた課題や知見について紹介していきます。主にAWS DMSやAmazon RDS ブルー/グリーンデプロイを用いたアップグレード方法の話になります。 DSチームのインフラ構成 DSチームはBASEの機械学習基盤を構築・運用しており、APIなどを介してプロダクト側へ機械学習モデルの推論結果などを返しています。学習・推論のために使うプロダクト側のデータはDMSを用いて、DS環

BASEアドベントカレンダー2021 10日目の記事です。 BASEアドベントカレンダー2021 10日目 BASE BANKでエンジニアをしている @budougumi0617 です。 マイグレーションファイルが含まれたPull Request（PR）が作られたとき、自動更新したER図をPRに追加するGitHub Actionsを作りました。 本記事では紹介するGitHub Actionsを利用すると次のようなメリットが得られます。 マイグレーションファイルをPRに出すだけでPRに更新されたER図が追加される 開発者は面倒なER図の更新作業から開放される レビューアはマイグレーションファイルを含んだPRをER図を見ながらレビューできるようになる プロジェクト関係者は常にメインブランチのマイグレーションファイルの状態と一致したER図を確認できる サンプルPR 自動生成したER図 TL;DR

この記事はBASE Advent Calendar 2022の9日目の記事です 同日公開の（この活動にも参加してくださっている） @yuripiiiii さんの「オンラインでのチームビルディングで意識をしていること」もぜひご覧ください！ ごあいさつ はじめましての人ははじめまして、こんにちは！フロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です 今回の記事では1年近く継続して実施してきた、 プロダクトの細かな不具合や使いづらい部分を有志チームで改善していく「#iikanji-pkb-kaizen」という活動 についてご紹介します！ なかなか利益に繋がっているかが計測しづらく、組織の間にボールが落ちてしまいがちな細かい不具合対応や改善をチームとして対応するために「どのようなことを考えて」「どのように進めて来たのか」を共有することで、読んでいただいた皆さまの組織でも実践する

まえがき こんにちは。Owners Experience Backend Group の杉浦です。主にサーバーサイドのアプリケーションの実装をしています。 エンジニアとして働いていると、当然、技術的なことには意識を向けるのですが、ROI（Return of Investment = 投資利益率）を意識することはあまりないと感じたので、この観点でエンジニアリングを考察しました。 想定する読者としては、下記を意識しています。 エンジニアの方で、ROIというビジネスの概念を知りたい方 エンジニアではない方で、ROIの観点でエンジニアリングの理解を深めたい方 このため、テックブログではあるものの、エンジニアではない方にも趣旨を理解いただけるように、技術に関しては少々噛み砕いて書いています。普段、コードには触れないビジネスパーソンの方にとっても、エンジニアリングを理解する一助になりましたら幸いです。

はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす

この記事はBASE Advent Calendar 24日目の記事です。 BASEテックブログ編集長の松原(@simezi9)です。 12月もいよいよ大詰め、クリスマス・イブということでそろそろ年内の仕事を納められた方もいるのではないでしょうか。 BASEのアドベントカレンダーも今年で 4回目となりました。 今年も全部で32本（一日で複数記事の日も作ったため）の記事を12/1~12/25の期間で投稿してきました。 本記事ではブログ編集長としてアドベントカレンダー運営に際して行ったことと、その振り返りをしたいと思います。 これは来年またBASEのアドベントカレンダーが無事に開催されること、 あるいは世の中のだれかがアドベントカレンダーを運営する際になにか1つでも参考になることがあればと思って書き残す備忘録でもあります。 タイムライン 編集部としてのアドベントカレンダーの準備のための流れは以下

BASE BANKでエンジニアをしている @budougumi0617 です。 この記事はBASE Advent Calendar 2021 10日目の記事…ではなく、New Relic Advent Calendar 2021 10日目の記事です。 qiita.com TL;DR ソフトウェア開発チームのパフォーマンスを示す 4 つの指標がある https://www.devops-research.com/quickcheck.html デプロイの頻度 変更のリードタイム 変更障害率 サービス復元時間 New Relic Oneを使って「デプロイの頻度」を計測してみた Event APIとNRQLでデプロイ回数をNew Relic Oneのダッシュボードに図示できる https://docs.newrelic.com/docs/data-apis/ingest-apis/introdu

こんにちは。BASE BANK 株式会社 Dev Division にて、 Engineering Manager をしている東口（@hgsgtk）です。 弊チームではプロダクト開発のリズムの中で振り返りを継続的に行っていますが、YOT という振り返りワークを作成、使用しています。BASE 社内の他チームでも「YOT っていう振り返り方法があるらしい！」と興味を持ってもらい活用されていたり、社外でもスクラムやアジャイル関連のカンファレンスでの登壇でちらっと紹介した際に「それ良さそう！」と一定の反響がありました。しかし、その一次情報はインターネット上のどこにもない状態でしたので、作成の背景も含めて参考にできる YOT の一次情報をここに記します。 TL;DR 振り返りの場のファシリテーターには、発言量が少なくてうまく場が盛り上がらない、というあるあるな悩みがありますよね 起こったことや思った

この記事は、「BASE Advent Calendar 2018」の9日目の記事です。 devblog.thebase.in 前日は id:match_1 でした。こんにちは、10日ほど前にデータベース移行についての記事を書かせていただいた植木です。 今回はインデックスとBtreeのパフォーマンスチューニング系のお話をしたいと思います。 概要 Btreeの構造などを説明している資料は他にもあるし、SQLのアンチパターンもある程度あるけど、何故アンチパターンになるのかなど構造を理解しながらの説明が無いように思っていました。今回はBtreeの構造を説明しながら、どのように動いてパフォーマンスに影響しているのかを説明しようかと思います。SQLのパフォーマンスチューニングはBtreeの構造を理解しているかどうかで全く違うものになります。構造を意識しつつ、誤解しやすいところや何故この処理でインデック

こんにちは。Product Dev Divisionに所属している大津です。 PHPカンファレンス2021 のトーク募集が始まりましたね。 僭越ながら、私は過去にPHPカンファレンス2019と2020に2回登壇したことがあり、今年もトーク応募をしてカンファレンスを盛り上げていこうと思っています！ そこで今後登壇する人のお力に少しでもなればと思い、トークするまでの流れを私なりにまとめてみました。 ぜひ参考にしてみてください！ 話したい内容を軽く決める まずは話したい内容をなんとなく決めます。 これは普段から思っていることでも良いですし、社内向けドキュメントとして書いた内容でも良いです。 はたまた、誰も話してなさそうなテーマだから自分が話してみよう！みたいな動機でも良いです。 大事なのは自分がトーク準備の過程を楽しめそうなテーマであるか？ということです。 ターゲットを決める どんな人に向けてト

こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ

BASE株式会社取締役 EVP of Developmentの藤川です。 世界中が新型コロナの影響で雇用の先行きが不透明な中、当社は引き続き成長を模索している状況で、マネージャ陣を中心に採用活動にも注力する毎日を送っています。 当社は正社員採用はもちろんのことですが、業務委託契約の方々にもお手伝いいただいておりますが、今回は業務委託契約にフォーカスした記事を書いてみたいと思います。 内製にこだわるチームを維持するための採用活動 私達はサービスを維持、成長させるために毎日ソースコードのメンテナンスをしています。我々はAWSやGCPなどのクラウドの環境とオープンソースのソフトウエアに恩恵を受けながら、独自のロジックは内製で開発しています。 他社の開発体制の事例として、スタートアップとして最初は内製で立ち上げたとしても、組織が大きくなりビジネスの成長が問われる中で、SIerさんに社内にがっつり入

こんにちはBASE株式会社取締役EVP of Developmentのえふしん( @fshin2000 ）です。 今回は、年末の給与改定から運用を開始する評価グレード制導入のお話を書いてみたいと思います。 これまで人材採用時の給与決定や社員の評価時には、マネージャ間で相談し役員承認の上で給与を決めていましたが、その基準や空気感は詳しく社内のメンバーに共有できていませんでした。理由として、中途主体の採用だとどうしても前職給与に影響され、人によって給与にばらつきがでてしまうため、体系だった形に整える機会がなかったのですが、今度、社内に評価グレード制というものを導入することになり、各給与レンジの方に求めるスキルや意識についてまとめたのでこちらで公開いたします。 評価グレード制というのは、一般的に等級と呼ばれるもので、一定サイズ以上の会社のご経験がある方なら、類する制度はどこでもあると思いますので

ServiceDev所属、サーバサイドエンジニアの栗田です。 現在私は、ServiceDevのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは主にQ毎にプロジェクトチームを編成し、チームで主体となって機能開発を行っていきます。 チームメンバー構成はプロジェクトの特性や規模により様々ですが、多くの場合、同じグループから1〜2名がプロジェクトにアサインされます。 今回はとある長期間プロジェクトで感じた事や・実際にこのように進めたよというところをサーバサイドエンジニアの視点から紹介したいと思います。 どんなプロジェクトだったか 今回紹介するプロジェクトは「BASE」の拡張機能である「BASE Apps」の1つである「商品オプション App」を開発するプロジェクトでした。 「商品オプション App」は商品にギフトラッ

はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その

Service Dev所属、サーバサイドエンジニアの宮村です。 現在私は、Service Devのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは最近、機能開発の際に設計レビューを行うようにしています。その取り組みについて紹介したいと思います。 開発チームについて BASEの開発チームは、メンバーが増えるに従って専門化する形でチームを分割してきました。 現在、サービスの機能開発を主に担当しているService Dev Sectionは、バックエンドが担当領域を分担して2Group、フロントエンド、ネイティブアプリを担当するそれぞれ1Groupの計4つのGroupから成り、Service Devのエンジニアはいずれかのチームに所属する形となっています。 （組織図について興味を持たれた方は、こちらの会社説明資料を

こんにちは。BASE BANK株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。私のいる開発チームでは、アジャイル開発の考え方・取り組みを取り入れています。アジャイル開発の導入については、「小さなチームが始めたアジャイル開発」という資料を公開しています。 今回は、アジャイル開発において、重要な振り返りについて、Mad Glad Sad(喜、怒、哀) というレトロスペクティブ（振り返り）のワークを紹介したいと思います。 TL;DR Mad Glad Sad(喜、怒、哀)は、感情データを集めるためのワーク イテレーションで起きた、喜んだり、怒ったり、哀しかったりした時間やイベント、を書き出していくイベント 素直な感情ベースでイベントを振り返ることで、 "理性のフィルター"で見つからない潜在的課題をチームが見つける きっかけに

これは BASE アドベントカレンダー 1日目の記事です。 devblog.thebase.in CTOの藤川です。ネットではえふしんと名乗っていて、会社でもえふしんさんと呼ぶ人が大多数です。 今年はテックリードの働きかけをきっかけとして、BASE社でもアドベントカレンダーを書いてみよう！という話になりました。皆様よろしくお願いいたします。 最近、エンジニアリングマネージャという役割が急速に普及し始めているので、今回はマネジメントの話について書いてみたいと思います。 IT業界にはエンジニア35歳定年説という都市伝説がまかり通っています。開発技術が進化してコードを書く労力が劇的に下がったにも関わらず、このことに恐怖してる人は少なくないようですし、何よりエンジニアがコードを書かなくなるような状態は望ましい状態ではないとされています。 一方で、成長するビジネスにおいては組織を作っていかないといけ

こんにちは、CTOの藤川です。 これまでエンジニアの肩書において、エンジニア専門職の上級職としてリードエンジニアという役割を設定しておりました。 リードエンジニアと言うと、世間の見方としては「技術力に優れたエンジニア」というやや漠然とした役割と想像しているのではないでしょうか？ Webサービス開発における「技術力」とは 「良いサービス」とは 「良いサービス」を提供するために、エンジニアに求められるスキル Webサービス企業におけるエンジニア属性：「テック」と「サービス」 「テックリード」と「サービスリード」の役割 リードエンジニア テックリード サービスリード 「サービスリード」とは、その一文字を直す作業に意義、喜びを感じられること 一緒に良いサービスを作りませんか？ Webサービス開発における「技術力」とは そもそも「技術力とは何ぞや？」というのが曖昧なことが多いです。 というのも、私共