はじめに はじめましての人ははじめまして、こんにちは！ 先週木曜日ぶり です！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回は 11/23（土） に開催された 「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」にスポンサリング・スポンサートークをしました！というご報告記事になります！ スポンサリングしたイベントについて 今回スポンサリングしたイベントは「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」というイベントで、スナック・ドリンクスポンサーの枠でスポンサリング・参加しました🙋 また、合わせてスポンサートークもさせていただきました！（詳細は後述） devx.jp DevX / Raycast Community Japan さんと 一般社団法人シンギュラリティ・ソサエティ さんの共催のイベントで、Fullstack AI Devの名前も冠している通り、AIを使った生産性向上、価値のあるプロダクトの提供に関心が強い方々の発表をたくさん聞くことができました！ また、Raycast Summitの名前も冠している通り、Raycastを使った便利な機能をはじめ、Raycast Proで使えるAI機能の紹介などなど「えっ、明日からRaycastもっと使いこなしたい！」となる発表や知見をたくさんお聞きすることができました！ スタッフの皆さん、登壇者の皆さんをはじめ、たくさんの方のご尽力のおかげでこのイベントが実施できたのだと感じています。このような素敵なイベントにスポンサーという形で関わらせていただきまして、本当にありがとうございました！ この場を借りて感謝をお伝えできればと思います！ スポンサートークでお話しした内容について 今回のスポンサートークでは、SLM（Small Language Model）の一つ、Gemini NanoがChromeブラウザに搭載されるようになり、どんなことに使えるのかについて、お話をさせていただきました！ 久しぶりのオフライン登壇で緊張しながら発表していた時の図 オンラインでも配信されており、100数十名に見ていただいていた時の図 登壇資料に関してはDocswellにて公開していますので、ぜひ合わせてご覧いただけますと幸いです！ www.docswell.com おわりに 以上、BASE BANKチームとして、「Fullstack AI Dev & Raycast Summit feat. Satoshi Nakajima」に協賛させていただきました！というご報告でした！ 今回のイベントはBASE BANKチームとして「エンジニアイベントに協賛させてください！」という発信を見てお声がけいただいたものでして、引き続きBASE BANKチームとしては規模に関わらずエンジニアイベント・コミュニティイベントにスポンサーとしてご協力させていただきたいと思っております！ 詳細は以下の記事にまとまっていますので、もしご興味あればぜひご覧ください！ devblog.thebase.in （私個人としてはスポンサートークの他、どんどん登壇もやっていきたいので、もし この辺りに書かれている発表内容 にピンとくるものがあればぜひご連絡ください！という宣伝もこっそりと…） また、BASE BANKチームはエンジニアをはじめ、各職種を大募集中ですので、もしご興味あればお気軽にカジュアル面談やXなどでお声がけください！ binc.jp

はじめに はじめましての人ははじめまして、こんにちは！BASE BANK Division（以下、BANKチーム）のフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 今回はBANKチームの中で職種横断で行っている「月次会」というLT会について紹介させてください！ この月次会（LT会）を毎月実施していることで、チームにとってどんなメリットがあるのか？や、実施における工夫を知っていただき、皆さんのチームでもスモールスタートで実施してみていただけるととっても嬉しいなと思っています！ また、今回は記事のタイトルの通り、その月次会で半年間（実際には2月~10月の計8回）、毎月様々なお題でLTをしたので、ついでにその内容とそこから得た知見もすこし紹介させてください！ もし、開催予定の技術イベントのテーマで合致しそうなタイトルがあれば X などで気軽にお声がけいただけると嬉しいです！ そもそも月次会とは？ 2022年11月からBANKチームで開始され、開始当時から以下のような想いと目的で実施されきたものです。 （この時期は僕はまだBANKチームにはおらず、BASE側のCRM機能の改善をしていたりしました） 社内のNotionには以下のように月次会についてまとまったポータルが誰でも見られる場所に設置されており、事業責任者の柳川（ @gimupop ）さんが目的を言語化して書いてくれていたり、ここに資料へのリンクがまとまったNotion DBが設置されていたりします。 この会に関しての情報がまとまったNotionページのキャプチャの一部 （BANKチームでのこの取り組みの前進になった「Product BEER BASH」という社内イベントとそれに対する柳川さんのアツい思いは以下のnoteにまとまって公開されているので、ぜひこちらもご覧ください。 👉 https://note.com/gimupop/n/nb950488d8de8 ） 月次会自体は上記Notionにも書かれているように 「自己開示」と「アウトプットをすることによるPDCAの体現」 を目的として実施されています。 そのため、発表する内容は仕事に関係していなくてもよく、フォーマットも自由（スライドを作ってもいいし、Lookerダッシュボードを見せながらでもいいし、Notionを上から説明していく形でも良い）なので、それぞれ5~10分間でかなり自由に発表しています。 今年からは会の運用を 「ローテーションのメイン枠（発表10分+感想・質問5分）× 4~6人」 「任意発表者枠（発表5分のみ）× 1~3人」 という2部構成に変えたので、発表の頻度としてはだいたい3ヶ月に1回、自分の番が来るぐらいのスパンで回っています。 実際に過去にあった発表だと以下のようなものがあります タイトル: 古着の話 古着の分類方法などの基礎知識や、古着屋さんがECに対してどんな課題感を持っているか？という知見の共有など タイトル: 今、恐竜が熱い お子さんがハマり、そこから参加したイベントや恐竜博物館の紹介、直近恐竜のこれまでの常識が変わってきている！という話、さらにはECでこんな商品を出そうかなと考えているアイデアの紹介など タイトル: もっとチームの皆さんとBANKプロダクトユーザーをみていきたい ユーザーインタビューの概要 & ユーザーインタビューとは？の共有など 発表は基本オフラインでみんな聞きながら、Figjamボードに付箋や絵文字、リアクションを貼ってワイワイしています。 発表者側としてはここに感想がたくさん集まっているのを後で見て嬉しい気持ちになれるし、ファシリテーターは非同期に質問や感想が集まっていくので発表後のタイミングで拾ったりしやすいというメリットがあります 🙌 gatchan0807がこの会を見てきて感じたこと BANKチームではこんな感じの会を毎月実施しており、2023年11月（ちょうど1年前）に異動して毎月参加してきて感じたことをざっくり書いておきます。 今の組織フェーズには月次会をやることでコミュニケーションが円滑になるなどメリットがたくさんあるなと感じています 🙋 発表起点で「こんなことやりたい」などを 異なる職種（アナリスト）の人に相談するきっかけになってよかった チームメンバーのパーソナリティを知る機会としてとても活用できる 入社時の自己紹介をしっかりできる場所 があるのはとても良い。どうしても仕事の中、ランチ・飲み会などで自己紹介できる量には限界があるし、話の流れが合致しないこともあるので… 後から入った人も、 長くいる人のパーソナリティを知る 機会になっている Lookerダッシュボードの場所を知れたり、Slackのどこでやり取りされているのか？のような「そんな情報がそこに眠っていたのか！」という気づきや「そうやってみればいいのね！」という 知識のインデックスが貼れる 発表方式にもPDCAが回っていて、最近はCanvaを使っていい感じのスライドをさくさく作って発表する人も出てきてとても良い 大体発表が3ヶ月に1回ぐらいなので、（任意発表で毎回やるとかしなければ）意外と話すネタは見つけやすい 逆に毎月発表はネタ探しとスライド作り大変だった（自業自得） こんなLTをしました ここからは記事タイトルの回収で、月次会で私がどんなLTをしていたかを紹介させてください。 もし、読者の皆さまのなかで何か琴線に触れるものがあれば、ぜひお話ししましょう！お気軽に X （ @gatchan0807 ）までお声がけください〜！🙌 2024年2月: Chrome DevToolsのススメ 実際に使った「Chrome DevToolsのススメ」のスライドの抜粋 フロントエンドエンジニア必携のChrome DevToolsの便利機能をベースに紹介 プロダクトマネージャー、デザイナーの確認作業を楽にする機能や、ネットワークが遅い場合、色覚特性の場合もかんたんに確認できる機能などを紹介 エンジニア以外の職種の方に「実は悪い人たちはこうやって使ってたりする」というのをイメージしてもらい、セキュリティ意識を高める事例も紹介 例えば、Chrome DevToolsを使うことで画面には出ていないこんなデータが見られる 例えば、Chrome DevToolsを使うことで画面を簡単に書き換えてキャプチャが撮れる 2024年3月: 戦略的自己学習のススメ 実際に使った「戦略的自己学習のススメ」のスライドの抜粋 前月にチームメンバーが「戦略的他者交流のススメ」というタイトルで発表をされていたので、それに関連させて話した内容 自分がどんな目的・考え方で調べ物（自己学習）をしているのかを話す自己開示の発表 コミュニケーションを円滑にするために事前に調べ物をしていること 考え事や調べ物のショートカットや、説明をうまくするために調べ物をしていること 2024年4月: （チーム全体でストレングスファインダーを実施する会になったのでおやすみ） ストレングスファインダーの会について、詳しくはこちらの記事をご覧ください basebook.binc.jp 2024年5月: ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ 実際に使った「ぼくのかんがえた さいきょうの じょうほうほぞんじゅつ」のスライドの抜粋 4月のストレングスファインダーの結果に「収集心」という性格特性がTOP5に入っていることから話すことにしたもの 3月の発表で自己学習の話をしていたので、そこで得た知識をどう蓄えているか？というところにフォーカスした内容 Notion、Google Keepなどを使った知識集積プラットフォーム構築を行った後、最終的にSlackに落ち着いている状態 2024年6月: ここがスゴいよ！JavaScript！ 実際に使った「ここがスゴいよ！JavaScript！」のスライドの抜粋 Arcadeというプロダクトを知り、そのプロダクトがChrome拡張 + Webアプリケーションで完結してプロダクトの価値を作っているのを見て、これを実現するためにはJavaScriptの力をふんだんに使う必要があるんだよ！という話 合わせて、JavaScriptを使ってできることを伝え、エンジニア以外のメンバーにもプログラミングや業務効率改善に興味を持ってもらえるように話した発表 2024年7月: もうすぐ来るオンデバイスLLM（SLM）の未来 実際に使った「もうすぐ来るオンデバイスLLM（SLM）の未来」のスライドの抜粋 2024年11月23日に開催されるイベント（ Fullstack AI Dev & Raycast Summit ）のスポンサーLTの内容の元になった発表 個人的にPWAの頃からChromeブラウザに興味が強いので、Google I/OでGemini nano in Chromeを知ったことから実際に触ってみて、得た知識を話したもの 合わせてGemini nanoがAndroidスマホに、Apple IntelligenceがiPhoneに入ることが話題になっていたので、それらも合わせて言及 これもエンジニア以外にもわかってもらえるようにイメージしやすい言葉を最大限使って発表 2024年8月: あなたの知らない.new ドメインの.世界 実際に使った「あなたの知らない.new ドメインの.世界」のスライドの抜粋 Googleが管理するgTLDの 「.new ドメイン」についての知見共有のための発表 https://docs.new でGoogle Docsの新規ページが作成できることなどを業務Tipsとして話したり 自分たちのサービスで作るならこういうドメインがいいかな？という候補を出したり おまけでNew gTLDで語呂合わせドメインが取れることを話したり、BrandTLDについても共有 2024年9月: Webの未来 / Web「ポータル」の未来 実際に使った「Webの未来 / Web「ポータル」の未来」のスライドの抜粋 expand.aiというプロダクトがY Combinatorから調達し、話題になっているのを社内で見つけ、それについて調べた知識を共有した発表 このプロダクトを調べている時にWeb上の情報ポータルサイトの未来を案じたので「こんな変化が必要な世界になりそう」という私見から話したもの expand.aiがどのように使えるのか？という知識に、前職の経験も組み合わせてポータルのポジションが危うくなりそう…という危機感がメイン サービスを継続提供するためにどんな解決策があるか、どんな価値提供が必要かを（ほぼ妄想ベースで）語ったりしました 2024年10月: 今日から始める生成AI 実際に使った「今日から始める生成AI」の未来」のスライドの抜粋 チームの生成AIの活用度合いをもっと上げたいと思い、生成AIに対してのスタンスを共有し、「ハードルをできる限り下げて使い始めてみよう。」というメッセージの発表 イメージしてもらいやすいように「ドラえもんだと思って使おう」というメッセージを伝えている のび太くんがドラえもんに泣きつくように、どんなことだって一旦相談してみてもいい ドラえもんのように失敗することもあるので、温かい目で失敗を教えてあげよう（完璧を求めすぎない） そこから派生して、ロールプレイプロンプトを使った利用時のテンションの上げ方や、JSONでやりとりする形での精度の改善などのちょっとしたテクニックも紹介 gatchan0807がこれだけ発表してきて思ったこと 月並みな表現にはなってしまうのですが、何より アウトプットを起点にした学習は定着が早いし、モチベーションの維持がとてもしやすいので良い なと思いました…！ また、生成AIに対して個人的な興味は強かったものの、プロダクトとして関わったり仕事として関わる見込みはほぼありませんでした。 ですが、積極的に発信していたことで生成AI関連のイベント（後述）へのスポンサリング + スポンサーLT担当をさせてもらう話が進んだり、実際に生成AIをプロダクトに組み込む方法を考え始めたりと（まだまだ構想・妄想段階）、もともとやりたいと思っていた仕事をやらせてもらえていたのですが、そこに追加して新たに生成AI関連のお仕事が増え、仕事をさらに楽しむ要因にもなりました 👏 チームに対しての知見共有も「わかりやすい！」や「学びがあった！」といったフィードバックや感謝を受け取れてとてもテンションが上がりますし、非常に勝手ながらBANKチームでこの会を一番うまく活用している人間なんじゃないかなと思っていたりします 😎 おわりに 今回はBANKチームの「月次会」という月に1回社内で行っているLT発表会の取り組みを紹介させていただきました。 もし、このような取り組みを行っているBASE / BASE BANKチームにご興味を持っていただけたのであれば、ぜひお気軽にカジュアル面談や X でのお声がけなどをしていただけますととても嬉しいです！ まだまだBASE BANKチームとしては作りたいもの、提供したい価値がたくさんあって、それらを一緒に実現していける仲間を募集しています。ぜひBANKチームにお力をお貸しください 🙇‍♂️🙇‍♂️🙇‍♂️ binc.jp また、合わせて gatchan0807 が半年間、毎月発表した内容も紹介させていただきました。 BANKチームとして、中小規模のエンジニアイベントへの会場提供・飲食スポンサーをやっていく動きもあるので、エンジニアイベントの主催、スタッフの皆さまの中で、もしこういった話にご興味ある方がいらっしゃればお気軽に X などでお声がけいただけますと幸いです！ もしくは、こちらの記事を X などでシェアしていただくのもとってもとっても嬉しいです！ devblog.thebase.in 最後に、記事内でも少し触れましたが 2024年11月23日（土）に実施される以下のイベントにBASE BANKチームがスポンサーをさせていただき、LTもさせていただきますのでぜひオフラインでご参加 or オンラインでご覧いただけると幸いです！ devx.jp

<この記事はHatena-Blog-Workflows-Boilerplateによって作成されました> こんにちは！ BASE株式会社 Pay ID の @zan_sakurai と申します。 BASE PRODUCT TEAM BLOG 編集局メンバーも務めています。(実は今年の編集長です。) 今回は、Hatena-Blog-Workflows-Boilerplateを使ってとあるSaaSのリンクを一括置換した話をします。 Hatena-Blog-Workflows-Boilerplate Hatena-Blog-Workflows-Boilerplateとは、 株式会社はてなさんが公式で公開している、はてなブログの記事を書くためのワークフローのボイラープレートでして、GitHub 上で下書きや記事の公開等を行うことができるものです。 github.com 弊社では昨年 @applepine1125 さんが書いた Hatena-Blog-Workflows-Boilerplateつかって BASEのブログ書いてみた も見ていただけると幸いです。 Hatena-Blog-Workflows-Boilerplate を使って 一括置換してみた 先に結論です。一括置換するまでは3ステップで完了しました! 総記事数約450件のうち、置換対象のリンクが含まれている記事は約100件、差分は約130行ほどでした。(目視で確認&置換していたらゾッとしますね...!) 良い感じに取り込んで(pull from hatenablog) 良い感じに置換して！ 良い感じにpush! 以上です! リンク置換作業の経緯 さすがに少し味気ないので、もう少し詳しく経緯もお伝えしようと思います。 ことのきっかけは、これまで利用していたとあるSaaSを別のSaaSに切り替えることになり、社内ではそのリンクの置換作業が行われている最中でした。 BASE PRODUCT TEAM BLOG に掲載している記事にも多くのそのSaaSのリンクが含まれており、置換作業が必要でした。 (ブログというコンテンツの特性上、過去の記事は更新しない、という判断もありえましたが、読者の皆様の体験を損なわないことを優先し、全て切り替えることとしました。) 最初は「全部記事目視で地道にやってみるか...。」と思っていましたが、量も量でしたし、「なんとかならないかな...。」とぼんやり考えていました。 ぼんやり考えているときと、ふとしたときに前述の @applepine1125 さんが書いた記事を思い出しました。 Hatena-Blog-Workflows-Boilerplate はブログの記事を書くためのワークフローを提供するものですが、 hatena blog上に掲載している記事をpullすることができるので、 それを使って、記事の取り込み(pull) -> 置換 -> push という流れで、リンクの置換作業を行うことができるのではないかと思いました。 ちょっと実験がてらやってみたところ、前述のとおり簡単にリンクの置き換えができました。 使ってみた感想 特定の文字列を一括置換という慣れ親しんだ(?)作業をおこなうだけでしたので、本当に簡単でした。 ブログの執筆の一連のフローを Hatena-Blog-Workflows-Boilerplate のワークフローに移行したいな、と社内でもぼやいていたのですが、 執筆のフローだけでなく、ブログのメンテナンスにも使えることがわかり、ますます今後活用したいと思っています。 また、今回触ってみて感じましたが、執筆だけでなく、メンテナンスや記事を一気に見る、といったことにも活用できるので、企業ではてなブログで技術ブログ等を運営されている方にはぜひ一度お試しいただきたいです。 おわりに Hatena-Blog-Workflows-Boilerplate めちゃくちゃ便利です...!!! open.talentio.com

BASE も Aurora MySQL v3 となりました SRE Groupの ngsw です。 2024/10/14〜10/15の深夜メンテナンスにて、BASEで利用しているAmazon Aurora MySQLのバージョンは、v2系からv3系となりました。 アップグレードの前提条件で大きなつまずきがありましたが、 gh-ost を利用することで、乗り越えることができました。 この記事では当該アップグレードの中で gh-ost をどのように利用し、どういう恩恵を受けたかについて述べていきます。 おさらい : v3 対応しないとどうなるの？ Aurora MySQL v2は標準サポート終了が発表されており、v3への移行を終えていないDBクラスターには自動的に有償の延長サポートが適用される流れです。 Amazon RDS 延長サポートの使用 - Amazon Aurora 2024/10/31 に自動で延長サポート入り 2024/12/01 より延長サポート料金の自動請求が適用される 費用はこちらをご確認ください。そこまで安くありません。 料金 - Amazon Aurora | AWS 有償サポート提供によりある程度の時間猶予が与えられたとはいえ、アップグレードを先延ばしにするメリットはほとんどありません。 たとえば、このアップグレードよりも企業にとって利益のある施策やサービスの開発/改修があればまた別の意思決定が働くでしょうが、そんな施策はそうそうないでしょう。 簡単にアップグレードできない問題 Aurora MySQL v2→v3アップグレード検証段階で問題が見つかりました。 BASEでは本番環境のデータにマスキングをほどこしたものを、開発環境で利用できるようにしています。 このマスキングしたDB Clusterで、以下にあるようなインプレースアップグレードの検証を行いましたが、エラーのためアップグレード処理は停止してしまいました。 Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード | Amazon Web Services ブログ 停止理由は upgrade-prechecks.log をみることで確認ができます。 原因となる問題は大きく二つありました。 mysql . event に関するアップグレード時の不整合エラー 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー mysql . event に関するアップグレード時の不整合エラー AWS サポートにより対応いただけました。 こちらは数日程度で解決でき、検証作業をブロックするほどの問題ではありませんでした。 多数のテーブルに古いディスクフォーマットで datetime 型カラムが作成されていたためのエラー 問題はこちらのエラーです。 MySQL :: MySQL 8.0: Removing support for old temporal datatypes 解決方法が「当該カラムを持つテーブルを新しく再作成する」ということになり、 Dump & Restoreする ALTER TABLE {table_name} FORCE; というような、つまりv2上で CREATE TABLE 相当のことを行う必要がありました。 おそらくはMySQL5.6以前のAWSのRDSで稼働し、そのままAuroraに引き継がれてきたテーブルで、かつ datetime 型カラムを含むものがこの対象となるのでしょう。 Aurora からサービスを開始したプロダクトなどでは見ることがないエラーなのかもしれません。 どのような困難が伴うか このあとに控える困難を想像し頭を抱えてしまった理由、今回の datetime 型カラム再作成対象となった2つのDB Cluster、XとYについて説明します。 X はショップの情報や商品の情報などを持ちます。 Y は各種履歴などが蓄積されています。 以下に規模感を記載します。 対象テーブル数とその合計サイズ テーブル数 容量 X全体 976tables 約7.5TB 対象テーブル 268tables 600GiB 対象テーブルはDB Clusterのデータサイズにして全体の約8% 4テーブルあれば、うち1つが対象という形。 テーブル数 容量 Y全体 236tables 約5.3TB 対象テーブル 37tables 615GiB 対象テーブルはDB Cluster のデータサイズにして全体の約11% 10テーブルあれば、うち1つか2つが対象という形。 結論としてこれだけのテーブルに対して、 なるべくサービス無停止でALTER文を発行しきる必要があります。 前提として、 当該アップグレードのメンテナンスは1回の深夜メンテナンスで行う 全断して行う予定であるが、メンテナンス時間は5〜6時間程度しかとれない というのがありました。 当初はメンテナンス時間の中で当該テーブルに対してdump&restoreするなども考えましたが、 実行時間的に無理だということがわかりました。 1 オンラインスキーマチェンジ/オンラインスキーママイグレーションツール メンテ当日にALTER TABLE or Dump/Restore + upgrade すべてを行うことは(当然に)無理、ということがわかりました。 それならばメンテ当日までに事前に下準備として行う方法を考えました。 下準備として、ということから暗黙的に無停止でなければなりません。 サービス無停止でALTER TABLE発行というところから、オンラインスキーマチェンジ/オンラインスキーママイグレーションツールに行き着くでしょう。 わたしはこの手のツールの利用経験がなかったため、ひとまず以下を候補にあげました。 2 pt-online-schema-change — Percona Toolkit Documentation github/gh-ost: GitHub's Online Schema-migration Tool for MySQL 結果として、われわれは gh-ost をはじめに検証し、目的に際し十分であると考え、そのまま今回の作業遂行ツールとして採用しました。 以下の理由から gh-ost の検証を優先し、結果的にわれわれの要件的には gh-ost で十分ということがわかったため、pt-osc の検証自体をスキップしました。 pt-oscよりgh-ostを優先して検証候補にした理由は以下になります。 pt-oscを選ばなかった : pt-osc では元テーブルと新テーブルの同期にトリガーが採用されており、トリガー利用による負荷が、サービス提供にどのように影響を与えるのか懸念し、検証優先度を下げた gh-ostを選んだ : 処理時間は長くなりそうではあるが、DB負荷自体は軽そうに思えたため gh-ostを選んだ : 一番の懸念であったDB Cluster Xでbinlog replicationをすでに運用していたため、gh-ost利用適正が高いだろうと思えたため そもそも pt-osc は完了までの処理速度を、gh-ost は小さな負荷での実行(つまりサービス影響の最小化)を重視しているよう思え、今回は後者の哲学を支持したため gh-ost 簡単にgh-ostの特徴および利用しての実感を書きます。 特徴については gh-ost/README.md at master · github/gh-ost を読むとわかりやすいです。 複数方式があるが、replication側からbinlogを取得するパターンが推奨されている 別名テーブルに元テーブルからデータを抽出して挿入する、更新分はbinlogで対応する 負荷が高くなると自動でthrottlingする 指定ファイルをtouchすれば、手動でthrottlingさせることもできる なにかしらのエラーが発生して処理途中で落ちた場合、また作業途中であった別名テーブルを削除して、最初から実行する必要がある 1テーブルにあたり、とてもゆっくり動くので対象テーブルデータ量によっては業務時間内に1テーブル終わるかわからないくらい 別名テーブルと元テーブルを切り替える処理をcut-overというが、この時間を指定することもできる(夜中に切り替えたい、昼間に切り替えたくない場合などに有効) cut-over という単語が出てきましたが gh-ostでは「ALTER TABLE用の別名テーブルを対象テーブルに変名し本番運用へと切り替える」ことをいいます。 gh-ost/doc/cut-over.md at master · github/gh-ost 利用していた実感では cut-over に至るまではまったく問題が起きませんでした。 明示的な問題として1回だけ発生したのは cut-over タイミングと更新タイミングが噛み合ったときに、 cut-over が止まってしまうという現象でした。 一度gh-ostの処理をとめ、新たにやり直すだけで解消するので、 cut-over 間近のタイミングだけ気にしておけばよい、という形で以後の作業もすすめることができました。 gh-ost の好きなところ 個人的に gh-ost で気に入ったところも書いておきましょう。 sock fileを経由することで対話式にコマンド実行が可能 gh-ost/doc/interactive-commands.md at master · github/gh-ost 進捗ステータスが確認できる コマンド実行中にパラメータを動的に変更できる 特定ファイルの設置で処理を暫定停止することができる 処理が遅いのだけが欠点、実運用への副作用がまったくといっていいほどない という感じです。 最終的にはほとんど放置して、一日の終わりに進捗状況を確認する程度になりました。 運用作業者(ひいてはサービス)に優しいツールだなと感じました。 参考 : 実際の作業スケジュール 当初は本番作業時にどのような影響がでるかわからなかったため、開発陣に対象テーブルのリストとALTER TABLE実行スケジュールを共有するようしました。 うまくいっても08月上旬から09月末くらいかかるのではないかと不安でしたが、gh-ostのおかげで08/08〜08/26という想定よりも短い期間で終えることができました。 データ総量が作業時間を左右する傾向がみられたため、見積もりのため以下のようなクエリでテーブルごとのデータの一覧を出しています。 total_size を主に見て実行時間の見積もりを行っていました。 SELECT table_schema, table_name, data_length AS `data_size`, index_length AS `index_size`, (data_length + index_length) AS `total_size`, table_comment AS ` comment ` FROM information_schema.TABLES WHERE table_schema != ' sys ' AND table_schema != ' information_schema ' AND table_schema != ' performance_schema ' GROUP BY table_schema, TABLE_NAME ORDER BY total_size DESC ; 注意点1 今回Aurora v2 -> v3 へのアップグレードだったため、gh-ost のバージョンは v1.1.5 を採用しています。 注意点2 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp には以下のような記述があります。 ユニークキーの追加 gh-ostを使用して、ユニークキーを追加することは可能です。 しかし、ユニークキーを追加するカラムの値が事前にユニークな値になっていることを確認してから実行しないと、 データがなくなってしまう恐れがあります。 われわれの今回の作業においては関係がなかったものですが、この記事より興味をもって利用される方においては、用途によっては気にしていただきたい内容であるため、ここに引用しました 参考URL 今回のタスクでは以下のDocumentを参考にしました MySQL 全般について MySQL :: MySQL 8.0: Removing support for old temporal datatypes gh-ost について gh-ost/README.md at master · github/gh-ost 第138回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その1］ | gihyo.jp 第139回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その2］ | gihyo.jp 第140回　オンラインスキーママイグレーションツール gh-ostを使ってみよう［その3］ | gihyo.jp 【MySQL】gh-ostを調べる - 地方エンジニアの学習日記 【MySQL】gh-ostでオンラインマイグレーション #Docker - Qiita Runtime error when trying to ALTER a table without PRIMARY KEY / UNIQUE KEY · Issue #332 · github/gh-ost pt-osc について pt-online-schema-change — Percona Toolkit Documentation pt-online-schema-changeの導入時に検討したこと、およびRailsアプリとの併用について - freee Developers Hub Percona社のgh-ostベンチマークなど Using gh-ost with Amazon Aurora for MySQL Gh-ost benchmark against pt-online-schema-change performance spirit というツールもあったが、v2(5.7系)だと利用が難しそうだった MySQL オンラインスキーマ変更ツールの spirit と gh-ost - Please Sleep BASEでは随時メンバーを募集しています。 2024.10現在、私の所属するSRE Groupの募集はないようですが、興味を持たれた読者諸氏におかれましては、以下リンク先をご覧いただければ幸いです。 採用情報 | BASE, Inc. - BASE, Inc. 検証ではdumpだけで想定メンテナンス時間をすべて消費してしまうことがわかりました ↩ チーム内にこれらツールの検証目的の過去Issuesが立っていたため ↩

新しい方を受け入れる側のマインドセットです。 はじめに BASE の Product Dev Division でシニアエンジニアをしているプログラミングをするパンダ（ @Panda_Program ）です。 入社されて3ヶ月目で同じチームで働いている Torata さんが「 入社して感じたBASEのいいなと思うところ 」という入社エントリを書いてくれたので、新入社員を受け入れる側からのアンサー記事です。 以下はBASE社内の人なら誰でも読むことができる文書で、特にこれからメンターになる人には読んで貰っているものです。自分が受け入れ側として数ヶ月間特に意識しており、手応えがあったことを書き残しています。 ここ数ヶ月の間、マネージャーと共にオンボーディングの体験や資料の全面的な見直しを行い、新入社員とメンターのオンボーディング体験を改善しました。この文章自体も前からあるものではなく、これからメンターはこういうことを心がけていこうねと新しく作ったものです。 以下の内容はBASE社での受け入れを想定していますが、他の会社でも（エンジニアという職種以外でも）活かせる内容だと思います。これから新しい方を受け入れるにあたってどう接したらいいのかわからないという方が、この文章を通して何かを掴めたら幸いです。 相手を知ろう これは一番重要です。現在、BASEで採用しているエンジニアは実務経験者の方がメインだからです。 よくある間違いは、相手が何も知らないと勘違いして一から全部教えようとすることです。相手も経験者なので一から教えてもらう必要はありません。では何を教えればいいのでしょうか。それは新入社員の人が持っている知識のうち、メンターから見て不足している部分だけです。 メンターがまずやるべきことは、新しく入社される方のこれまでの経験を深く知ることです。メンターはチームメンバーの誰よりも新しく入社される方のバックグラウンドを理解しましょう。 前職ではどのような業務を担当していたのか、前職の会社の雰囲気はどのようなものであったのか、どのようなことに興味を持っていて、どのようなことが苦手なのか。これらのことを知っていると自然と相手への向き合い方も変わります。相手の良いところや自分にない部分を知ることは相手へのリスペクトにつながります。 BASEではこうだと押し付けるのではいけません。相手の過去の経験を知り、BASEとの共通点や相違点を提示しましょう。すると相手は一から全部知るコストを払う必要はなく、共通点や差分を学ぶだけで済みます。メンターが「ウチではこうだ」と押し付けるのではなく、転職者が自分の過去の経験に基づいて、新しい会社と今までの会社との共通点や相違点にフォーカスする方がスムーズです。結果的に組織やカルチャーへの適応も早くなるでしょう。 自分を開示しよう 新しく入社される方はたくさんの質問を受けることでしょう。しかし、相手のことを聞くばかりではいけません。自分はどういう人間か、会社やチームで働いている人はどういう人たちなのかを伝えることも重要です。 自分の経験を相手に伝えましょう。自分は何が得意で、なぜこの会社で働いているのか。オンボーディング期間は、普段会社ではあまり話すことのない、自分が大切にしている価値観について話すいいタイミングです。ここを逃すとなかなかそれを話すタイミングはありません。 メンターとメンティーの一対一に限らず、新入社員の方が所属するチームのみんなで自分たちの大事にしている価値観について改めて話す機会を設けることにより、メンバーの知らなかった一面も見れるかもしれません。そうすれば、チームの結束はさらに強まるでしょう。 オンボーディングという機会を活用して既存のチームを再ビルディングすると、メンバー同士が今よりもっと互いにリスペクトを送り合えるより強いチームになります。 ドキュメントは渡すだけではなく、相手の理解度に合わせて適宜一緒に読もう。口頭で解説・補足をしよう オンボーディングで最初にやることの一つは、自分たちが開発しているプロダクトを実際に触ってみることです。その際、メンターは新入社員を一人きりにしないであげてください。 一般的に、何かウェブサイトやソフトウェアを触るときにこの裏側はどうなっているんだろうと気になるというのがエンジニアの性（さが）です。新しく入った方は、これから自分が開発していくことになるプロダクトに自然と興味と疑問を持ちます。 興味から出た感想や疑問に対してメンターがシステムの裏側を解説したり、ここはちょっといけてないところなんだよねと共感したりとタイムリーに答えることで、メンティーの知識の定着度は俄然アップします。人は疑問を持った時が一番知識を吸収できるからです。また、このように相手に寄り添った行動の積み重ねがお互いの信頼関係を構築することに繋がります。 ソフトウェアに限らずドキュメントも同様です。一人でただ読むだけでは理解できないことも、メンターと一緒に読みながら適宜口頭で補足や解説を交えてもらうとメンティーは深く理解することができます。 この時、自分で解説を始めたりBASEの事情を一方的に伝えるだけではなく、「この中でどの部分がわからないですか」「あなたの前の会社ではどうでしたか」とまず質問をして話を聞いてあげましょう。そこからうちの会社ではここは違いますね、ここは同じですねという会話を広げていきましょう。 「相手を知る」チャンスはどこにでも転がっています。 おわりに 少し大袈裟ですが、メンターとなるあなたの印象がBASEの社員全体の印象を決めると言っても過言ではありません。もし相手が年下だったり自分より経験が浅くても、相手へのリスペクトを忘れず真摯に向き合いましょう。 なお、手前味噌ですが私の配信しているラジオコンテンツもお聞きいただけると、オンボーディングに対してさらにイメージが湧くかなと思います。 こちらは、オンボーディングしてもらう側特有の焦りからくる失敗などについて話しています。オンボーディングされる側の気持ちを少しでも思い出すきっかけになるかと思います。 BASEではソフトウェアエンジニアを募集しています。ぜひ採用情報ページをご覧ください。 採用情報 | BASE, Inc. - BASE, Inc.

はじめに BASE BANK Division で エンジニア をしている岩本と申します！ YELL BANK の開発を担当しています。 2024年5月にBASEへjoinして早いもので5ヶ月ほどが経ちました。 joinしてからいくつかのプロジェクトを担当してきました。 改めて考えるとオンボーディングがとても充実していたおかげで円滑にプロジェクトに入っていけたのだなぁと感じます。 そこで、オンボーディングを中心にこれまでの5ヶ月を振り返りつつ、チームが新規メンバーのキャッチアップに向けて、どのような取り組みを行っているかを紹介させて頂こうと思います！！ 前置き 本題に入る前に前置きです。 私の普段の業務をイメージしやすいように体制や役割、各種環境についてお伝えします！ 体制 まずは体制です。 私の担当する YELL BANK ですが、joinした5月時点では以下のような3名体制で開発していました。 EPM（Engineering Program Managerのことです。 こちら をご参考ください。） エンジニア2名（内1人が私） 7月以降は以下の体制に移行しています。 EPM エンジニア1名（私） 役割 次に役割です。 私はエンジニアですが、BASE BANKでは「フルサイクルエンジニア」という役割が求められます。 フルサイクルエンジニアについての記事は過去にGroup Managerの松雪さん( @applepine1125 )が書いた こちら をご参考ください。 そのため、企画・要件定義〜保守運用・データ分析支援等まで幅広く対応することが必要になります。 それにより、開発チームだけでなく、PdM、デザイナー、PMMといった職能のメンバーとも頻繁にコミュニケーションが発生します。 体感的には開発チーム：7、PdM・PMM・デザイナー：3くらいの割合でコミュニケーションしています。 出社頻度 コミュニケーションに関連した話ですが、現状、BASE BANKの開発チームでは週1（毎週木曜）に出社日を設け、その他はリモートワークです。 開発環境 最後にアーキテクチャ周りのお話です。 私の担当する YELL BANK の開発業務においては以下の図の上側にあるBASEのサービスと下側にあるBASE BANKのサービス群を実装しております。 ご覧の通り、フロントエンドはTypescript（Vue.js）、バックエンドはPHP、Go、Pythonという形で複数の言語で開発しています。 また、インフラは主にAWSを使用しており、IaCではterraformを使用しています。 本題 前置きが少々長くなりましたが、ここから本題です。 私が効果を感じた取り組みなどを5つ紹介させて頂きます！！ その1　オンボーディングクエスト BASE BANKチームではオンボーディングクエストを用意しています。 以下はNotionで作成したオンボーディングクエストのTOPページになります！ 新規メンバーはまずクエストに沿って開発環境構築等の各種セットアップをしていきます。 さらに開発環境構築だけでなく、プロダクトの説明を受けたり、実際に触ったりといった研修も行います。 オンボーディング中はメンターが1人付きますが、クエストの中でPdMやデザイナーといった他の職能のメンバーとも接します。 フルサイクルエンジニアとしてはコードが書けるというだけでは不十分です。 そのため、プロダクトの研修があったり、他の職能のメンバーとコミュニケーションできる機会があったのは業務を進めるのに大変助かりました！ また、クエストではオンボーディングタスクというものを用意しています。 簡単かつ業務を1サイクル回せるといった最初のキャッチアップにちょうどよいタスクのことです。 私の場合、if文を少し修正すればOKな簡単なコード修正と、それをデプロイするというタスクでした。 これにより一通りの開発の流れを把握できました。 クエストはオンボーディングが終了するたびに振り返りをして改善を重ねています。 その2　オンボーディング期間中は毎日出社 オンボーディング期間は1〜2週間です。 その間、基本的には新規メンバーもメンターも毎日出社します。 そのため、すぐにメンターや他のメンバーに質問することができます。 対面なので、解決も早いです。 それ以上にメンバーとの信頼関係をかなり早く構築できるというメリットを感じます。 リモートの場合、コミュニケーション量が少なくなる傾向があるため、出社による対面のコミュニケーションでレクチャーを受けられたことでシステム、プロダクトのインプット量・質も上がりました。 今振り返ってみても最初に出社していたことでオンボーディング後の業務を円滑に進めることができました。 また、入社前・直後にコミュニケーションに不安を感じる方は多いとは思いますが、BASEでは早期にそのような不安を解消することができました！ デメリットとして通勤の負荷はありましたが、それを超えるメリットを享受できたと感じています！ 前置きでも記載した通り、オンボーディング終了後は週1（毎週木曜）で出社しています。 その3　ドキュメント文化 オンボーディング終了後、いざ本格的な業務に入るわけですが、まだまだ分からないことはたくさんあります。 BASE BANKにはドキュメントを残す文化があります。 分からないことがあればNotionやREADMEを見れば答えに辿り着くことも多いですし、あるいはなにかしらのヒントがあることが多いです。 業務していると大抵、どのメンバーも同じことで困るパターンも多いので、そんなときのためにトラブルシューティングをまとめたドキュメントも存在します。 個人的にはオンボーディング直後はこのドキュメントに大変助けられました。 以下はそのトラブルシューティングのドキュメントを一部抜粋したものです。 その4　メンターランチ BASEにはメンターランチという制度があります。 入社後、主に業務で関わるメンバーとランチするというものです。 費用は会社負担です。 この制度により、自分で機会を設けずとも仕組みでコミュニケーションの機会を設けることができます。 プロジェクト開始前にエンジニア以外の職能のメンバーともお話できたことで、いざプロジェクトを進めるというときにやりやすかったのを覚えています。 その5　振り返り文化 BASE BANKではスプリントごとにも振り返りしますが、それぞれのプロジェクト後にも振り返りをする文化があります。 プロジェクトの振り返りは職能横断的にそのプロジェクトに関わったメンバー全員が参加します。 私個人としては振り返りの場はプロダクトを知る機会でもあり、人を知る機会でもあります。 その人の職能、経験によって色々な意見が出ます。 そして自分も意見を出します。 意見を出すということはプロジェクトやプロダクトについて、常に能動的に考えている必要があります。 振り返り文化のおかげで自然とそのような考えになっているように感じます。 つまり、自然と「早くキャッチアップしなきゃ」という気持ちになります。 まとめ 改めてこれまでの4ヶ月を振り返ってみました。 振り返ってみると円滑なコミュニケーションというところにBASE BANKの強みがあるのだと感じます。 そして、それによるチームプレイに強みがあるのだと感じます。 私自身はまだまだ全般的に知識が不足しているので、チーム力向上に寄与できるように邁進します。 おわりに BASE BANKではいっしょに働く仲間を大募集しております！ フルサイクルエンジニアという役割に興味があるという方はまずはカジュアル面談からでもご応募頂けるとうれしいです！ ↓の採用ページの募集職種一覧から、BASE BANKチームで6.金融サービス（BASE BANKチーム）を選択頂いてカジュアル面談にご応募できます！ binc.jp

こんにちは！ BASE BANKです。 最近は大きなカンファレンスだけでなく様々なコミュニティのオフラインイベントも増え、かつて以上の活気で溢れているなと感じています。 我々BASE社も大小さまざまなカンファレンス、イベントにスポンサーをさせていただいておりますが、今回はBASE BANKとしてももっとスポンサーの頻度をあげていくぞ！スポンサーさせてください！という内容の記事です。 BASE BANKって? スポンサーの理由やイベントとのマッチングのために、まずは軽くBASE BANKについて自己紹介させてください。 BASE BANKはBASE社の1事業部です。 「銀行をかんたんにし、全ての人が挑戦できる世の中に」というミッションを掲げ、個人やスモールチームの資金繰りに関する課題解決を行っています。 https://speakerdeck.com/base/basebank 現在、「BASE」のショップオーナー向けには、「YELL BANK」、「BASEカード」、「お急ぎ振込(振込申請)」の3つを提供しており、グループ会社のPAY.JPと協業し「PAY.JP YELL BANK」として「BASE」以外のプラットフォームへも広く価値提供をし始めたところです！ 8月に公開したIR資料からもわかるように、ありがたいことに「YELL BANK」を筆頭に各プロダクトがめちゃくちゃ順調にグロースしています。 しかし、もっとBASEグループ全体をリードできるような事業部へと成長していくために、現事業のグロースと新規事業の創出の2軸をフルアクセルで推進しています。 https://contents.xj-storage.jp/xcontents/AS08546/360b2858/87ab/484c/9da2/062c0fb17663/140120240806563776.pdf 現在、エンジニアとBizdev、事業企画のポジションをオープンしていますが、特にエンジニアを積極大募集中です！ https://open.talentio.com/r/1/c/binc/homes/4380?group_ids=9203 なんでスポンサーしたいの? スポンサーをしていきたい理由の１つは事業部の認知度向上のためです。 BASE社としては、ありがたいことにこれまでのスポンサーの積み重ねやCMなどを通じて認知してくださっている方が多くいらっしゃいます。 しかしBASE BANKという事業部としてはまだまだ認知度に伸びしろがあり、”BASEってECだけじゃないんですね！”とスカウトやイベントなどで初めて知っていただく機会がまだまだ多いです。 上にも書いたように、さらなる提供価値や提供顧客の拡大のために現在フルアクセルで事業と組織の増強をおこなっているところですが、まだまだ仲間が足りません。 めちゃくちゃおもしろいことやってる事業部があるよ！やっていきたいことのためにまだまだ仲間が必要だよ！というアピールの場を増やしていきたいと考えているのが1つ目の理由です。 理由の2つ目として、コミュニティの発展をサポートしていきたいという思いがあります。 コミュニティやイベントの存在が日々のトレンドキャッチアップやアウトプットの起点にもなり、さらにそれを通じた”ゆるいつながり”が生まれることで会社の組織文化を見直すよい機会にもつながったりします。 我々もこういったコミュニティの恩恵を受けてきたこともあり、会社としても昔から様々なコミュニティへスポンサーとして微力ながら応援をさせていただいていました。 これまではPHP ConferenceやGo Conferenceなど、比較的大きなイベント、コミュニティへのスポンサーがメインでしたが、より細かく継続的にBASE BANKを知ってもらえる機会を増やしたい、コミュニティの裾野を広げるお手伝いをもっとやっていきたいという思いもあり、今回スポンサー立候補をするに至りました。 一緒に組んでいきたいイベント、コミュニティ BASE BANKとしても、事業や組織のあり方、技術スタックと親和性の高いコミュニティ、イベントとタッグを組んでいきたいと考えています。 具体的なジャンルとしては以下を想定しています。 事業領域 Fintech EC 開発プロセス スクラム アジャイル プログラミング言語 PHP Go TypeScript(React, Vue) 規模としては~100人規模を想定しています。 あくまで現時点での想定なので、上に書いた以外でも理念に強く共感させていただいたり、親和性の高さを感じたコミュニティやイベントとのご縁があればぜひお手伝いさせていただきたいです！ BASE BANKとしてご提供できるもの 会場スポンサー 東京都港区六本木三丁目2番1号 住友不動産六本木グランドタワー 37F 最大50名程度収容可能(椅子、テーブルありの場合) レイアウト例 (約40名規模のイベント) https://devblog.thebase.in/entry/welcome_fintech2 発表用の演台があり、その左右にプロジェクタを使って投影することができます。 飲食スポンサー 予算は10万程度までを想定しております。 一旦10万以下とさせていただいておりますが多少調整は効くので、予算と提供するドリンクや食事については都度ご相談させてください！ イベント時にさせていただきたいこと イベントの何処かのタイミングでBASE, BASE BANKの会社紹介をさせてください！ 3分程度お時間を頂戴します。 ご連絡先 とりあえず話を聞いてみたい！というだけでも構いません。以下フォームからぜひお問い合わせください！ https://binc.jp/contacts/jobs 会場や予算の確認のため、イベント開催の1ヶ月前にはお声がけいただけると幸いです。 おわりに 今回ブログとして告知を出させていただきましたが、こちらからも積極的に直接お声がけさせていただきます。 また、事業を一緒に作っていく仲間も大募集中です! https://open.talentio.com/r/1/c/binc/homes/4380?group_ids=9203 少しでもご興味ある方は是非お話しましょう！

はじめに BASEのProduct Dev / Feature Dev1 GroupでアプリケーションエンジニアをしているTorataです。 BASEに入社して早くも3ヶ月がたちました。 少しづつBASEの仕事や環境、文化にも慣れてきたので振り返りを兼ねて入社エントリーを書こうと思います。 BASEに興味を持っている方の参考になれば嬉しいです！ 入社の経緯 前職では、新卒から約5年間、バックエンドエンジニアとして働いていました。 周りには信頼できる素晴らしい方々が多く、幅広い経験をすることができました。 ただ自身のキャリアを考えたときに、より大きなチームで大規模なシステムを扱う経験を積みたい、その中でさらにエンジニアとしての専門性を高めていきたいと思い転職を決意しました。 BASEに入社した理由は、ビジョンに共感し、成長できる環境が整っていると感じたからです。BASEのプロダクトは「個人やスモールチームをエンパワーメントする」ことにフォーカスしており、誰もが大きな組織に頼らずとも活躍できる時代に非常にマッチしたサービスだと感じました。 また、私の身近な人もBASEを利用していたこともあり、彼らのような人々を支えたいという強い思いが芽生えました。 さらに、BASEのエンジニア組織ではカンファレンスでの登壇や、現在私が書いているテックブログのような発信活動が盛んに行われており、そうした環境で自分が成長できる姿をイメージできたことも、入社を決めた大きな理由です。 BASEのいいなと思うとこ 1. チーム外のメンバーと交流できる機会がたくさんある BASEでは、入社後8回までチーム内外のメンバーとランチに行ける「メンターランチ」や、3ヶ月に1度オフィスで開催される「締め会」、午後7時以降にオフィス内のバーカウンターでアルコールを含む各種ドリンクを楽しむことができるなど、社員同士が交流できる機会が多く設けられています。 私も入社してからチーム内外の多くの方々と交流することができました。 私は前職は毎日オフィス出社の会社だったのでハイブリットワークを実施しているBASEでのコミュニケーションの取り方に不安があったのですが、なんなら前職よりも他の方と話す機会が多いんじゃないかと思うくらいにコミュニケーションを取れる機会が多く設けられています。 コミュニケーションを通してどういう人か分かっている方が業務もスムーズに進められるし、こういう機会を通して普段業務では関わりのない人とも交流を持つことができるので大変助けられています。 2. 「Move Fast」で支え合う文化がある チャットで困りごとや疑問を呟くと、すぐに多くのメンバーが助けてくれます。 特にオンボーディング期間中は、新しい環境に対する不安や疑問が多かったのですが、何度も助けてもらいました。 実際、自分のオンボーディングチャンネルに「ここってどうなっているんだろう？」とか「これ詰まっちゃったなー」みたいな困りごとを雑に投げても誰かしらがそれを拾ってくれて説明したり解決まで持っていってくれます。 細かな疑問やちょっとした悩みにも迅速に反応してもらえることで、何かあった時には誰かが助けてくれるという安心感と、もし困っている人を見かけたら自分も同じように助けてあげたいといういい循環ができているなと感じています。 BASEにはMove Fast以外にも行動指針があって、これらの”BASEらしさ”を個人的には魅力に感じています。 3. モダンとレガシー2つの環境を経験できる BASEは10年以上続いているサービスであり、長年使われてきたリポジトリと、リプレイス先の新しいリポジトリの2つが存在しています。 新しいリポジトリではモジュラモノリスが採用されており、現代の水準に合ったクリーンなコードに触れることができます。 一方で、古いリポジトリも改善が進められており、レガシーコードにどう立ち向かっていくかを経験できます。 エンジニアとしては常にモダンな環境で開発をする方が楽しいかもしれませんが、現実的にはレガシーコードとも向き合うことが避けられないと個人的には考えています。 モダンとレガシー2つの環境を経験することでエンジニアとして大きく成長できるんじゃないかと今からワクワクしています。 今後やりたいこと 私の周りには、非常に優れた、尊敬できるエンジニアが多くいます。まずはそのレベルに追いつくことを目標に、日々努力しています。 現在は多くを学びながら、チームのサポートを受けている段階ですが、将来的には「自分だからこそできる」貢献を模索し、チームや組織に新たな価値を提供できるエンジニアを目指したいと考えています。 おわりに 以上で私のBASEの入社の経緯や入社していいなと思うところを紹介しました。 この記事を読んで少しでもBASEに興味を持ってもらえたら嬉しいです。 BASEは現在エンジニア積極採用中なので興味があれば採用情報ぜひご覧ください！ BASEで一緒に働きましょう！ binc.jp

はじめに こんにちは。Product Management Group で プロダクトマネジメント をしている坂東（ @7auto ）です。 リソース的な問題で「やるべきことがたくさんあって、小さめの改善やPJに手が回らない」そんなお悩みを持つ方はたくさんいらっしゃるのではないでしょうか。 サービスが大きくなるとPJの規模も大きくなっていきます。その結果、小さめのPJや改善の優先度が下がりがちになります。 一方で、小さめのPJや改善はサービス利用者の声から生まれることも多く、これを放置し続けることはサービス体験の悪化に繋がります。 そこで大きなPJと並行して、こうした小さめのPJや改善に対し「最小のコミュニケーションコストで機能リリースする」というコンセプトで立ち上げからリリースを行いました。 「全員集まったのはキックオフと振り返りだけ」そんな定例もDailyも無いPJを通して、低コストなだけでなく個人の成長にもつながるメリットがあるように感じられました。 本稿ではそこから得られたことを共有できればと思います。 低コストをコンセプトにした背景 当時、自分は本件の他に3PJ（そのうち開発が2件）を同時進行していました。 他のPJではアジャイルな開発方式を取っており、毎週スプリントイベントDailyMTGを実施しながら漸進的に進めていました。 アジャイルな開発方式を取ることで不確実性への対処は容易になる一方、コミュニケーションに割く時間が大きくなります。 そのため、３開発をアジャイルにすると時間的な面で自分がボトルネックになる懸念を感じました。 そこで、開発規模が一番小さかった本件のPJはアジャイルにとらわれず、できるだけコミュニケーションコストを下げるようPJを設計しました。 メンバー構成・削ったこと・スケジュール感 このPJメンバー構成はプロダクトマネージャー（自分）、デザイナー、バックエンドエンジニア、フロントエンドエンジニア、プロセスエンジニア、直接手は動かさないプロジェクトマネージャーの６名で、それぞれが別のPJも兼務していました。 プロダクトマネージャー、デザイナー、エンジニアは一緒に仕事するのが初めてのメンバー同士でした。 また、各メンバーが別のPJを兼務している都合上、全員が揃うのを待つことはせず、各工程をFIXさせて次の工程に進めるウォーターフォールに近い形になりました。 実際のリリースまでのスケジュールはざっくりと以下のような流れになりました。 2週間：PdMが企画・ドキュメント化 2週間：デザイナーがUI/UXを確定 4週間：エンジニアが開発 2週間：PEがQA リリース コミュニケーションを削れるだけ削ったため、リリースするまでに全メンバーが顔を合わせたのはキックオフだけで、アドホックなMTGも数えるほどでした。 PdMとして気をつけていたこと コミュニケーションを削るということは、デザイナーやエンジニアはドキュメントから必要十分な情報を引き出せる必要があることを意味します。 なので企画の段階で体験やお問い合わせ時の対応なども考慮し、要件・体験・実装を意識したPRDを作成していきました。 それでもいくつか質問を受けるケースがありましたが、質問を受けた際は2分以内で答えるくらいの気持ちでやりました。 *1 結果的に特に大きなトラブルもなくスムーズにリリースできました。 このPJを通して得られたこと 低コストで大きな手戻りもなかったので、全体的にスピーディーに無駄なく価値提供できました。 今回のような方針でPJを設計することで、手が回りにくい小さめのPJも並行して動かせると感じました。 また、リリースを通して客観的に自身を見直す機会を得られたことも非常にポジティブにとらえています。 ウォーターフォールに近い開発スタイルとなったことで以下を意識する必要があったため、（仕事をする上で当たり前でありますが）普段の仕事の姿勢を改めて考える良い機会になりました。 自身で作成したスケジュールに責任を持つ 情報伝達の内容に責任を持つ 状況変化に対する報連相の意識が高める 特にこのPJではDailyもないので「明日共有すればいいや」という気持ちにならなかったことが大きいと感じました。 また、自身のドキュメンテーションの質を客観的に見直す良い機会となりました。 PdMとしてはドキュメントで必要十分な情報を伝えなければならなかったことで、以下を改めて意識することになったためです。 不明瞭さを残さない 無駄なことを書かない 読み手のコンテキストを意識する 最後に、今回は小さいPJかつ初めてのメンバーとの仕事だったので、PJ運用でトライしたかったことを小さく試すことができました。 PJ規模が大きくなると、PJ運用のスケジュールへの影響も無視できないため、積極的なトライがしにくくなります。 そのため、こうした方式のPJは実験、息抜き、マンネリの解消といった意味も持たせることができるように感じました。 おわりに 小規模なPJであれば、コミュニケーションを削ぎ落としてPJの並列数を増やすことができました。また、副次的に仕事の質やプロセスを見直すという価値も持たせることができました。 小規模の開発に割くリソースがない方、時間がないとお悩みの方、いつものやり方にマンネリを覚えている方は、勇気を持ってどこまで軽量にリリースできるかを楽しんで見てはいかがでしょうか？ 最後に宣伝です。BASE ではプロダクトマネジメントをするメンバーを募集しています。 興味がある方は下記の紹介資料や、採用情報もぜひご覧ください。 binc.jp *1 : リリース後の振り返りでエンジニアからFBを頂いたのですが、すぐに返答することがDaily（強制的に集まって問題を確認する場）を設けずに済んだ要素になっていたようです。

はじめに はじめましての人ははじめまして、こんにちは！BASE BANK Divisionのフロントエンドエンジニアのがっちゃん（  @gatchan0807  ）です。 ネットショップ作成サービス「BASE」の開発チームからBASE BANKチームに 社内異動をして 、チームの人数が半分以下のチームになってから約半年が経ちました。 そんなチーム環境の変化と共に、私がどんなことを考えるようになったのか、BASE BANKチームとはフロントエンドエンジニア目線でどのようなチームなのかを、「小さなチームでフロントエンドエンジニアという職種で働くことの面白さ」と合わせて紹介させてください！ 個人的には、今回紹介するような活動をすることでプロダクトを前に進めてユーザーに価値提供することもできるし、ビジネスの成長にも寄与することが出来るだろうと考えているので、読んでくださった皆さまの参考になれば嬉しいです！ チームの面白さの紹介の前に… チームの紹介をする前にまず、ちょっとだけ私の自己紹介がわりに私が「フロントエンド」という業務領域をどう捉えているのかについて共有させてください。 ひとことで言うと、私はフロントエンドを「データ（システム）とユーザーの 境界面 である」と考えています。だからこそ、とても面白くて大好きな領域なのです。 もう少し具体的なお話をすると、サービス・プロダクトを利用しているユーザーは画面に表示されているデータしか知り得ません。それは、社内用の管理画面であってもBASEやPay IDが提供しているサービスであっても同じです。 この前提に立つと、 UIを実装するフロントエンドエンジニアが正しくUIに表示させる事ができないと、ユーザーに対して正しく価値提供が出来ない ということになります。 さらに、その実装者であるがゆえに、デザイナーよりも そのプロダクトの「挙動」に対しての深い知識がある とも言えます。 具体的には、APIやDB、DOM上にのみ表示されている、画面には見えないデータの扱い方とそのデータに基づいたUIのパターンにも深い知識があるし、そうあるべきと言えます。 つまり、フロントエンドが境界面になるからこそ、 ユーザーへの価値提供とUIのパターンの管理に責任を持つことが重要な職務 だと私は捉えています。 フロントエンドエンジニアの責務を全うするためにアンテナを張る場所 上述のとおり、フロントエンドエンジニアは画面に何がどう表示されているのかに責務を持つと考えているので、私は 「ユーザーからのお問い合わせ」と「素早く目に見えるUIを作る手段」に感度高くあることが重要 だと考えて常々そこにアンテナを張るようになりました。 前提として、お問い合わせは「ユーザーが実際に画面で見たもの」を元に行われています。 ここに関して、もう少し具体的に解説していきます。 「お問い合わせ」はUI改善の起点になるありがたい機会 これをもう少し抽象的に書くと「ユーザーが、とあるパターンのUIで表示された情報を見て 困った・迷ったポイントのうち、サービスを利用する上でクリティカルで熱量が高くなる部分の不備 」 を教えてくださっている 状態です。 これは、フロントエンドエンジニアにとっては「どのパターンのUIをみるとそのような問い合わせが生まれるのか？」「その課題をどう解決するべきか？」を考えることに使える、ひじょ〜〜〜にありがたいキッカケだと捉えています（さらに、各種テストケースの拡充や新機能の仕様考慮時の助けにもなります） 少し話はそれますが、現在BASE BANKチームでは、お問い合わせ内容の管理用ツールZendeskとSlackの連携を行っており、お問い合わせの具体的な内容をチーム内で確認できるSlackチャンネルにも流しています。そのため、チームメンバーは誰でも直近頻発している問い合わせ内容を察知したり、一次対応の内容を検討しているスレッド内でエンジニアやPdMを呼んで来て仕様面や技術面での確認や調査を行うようになっています。 Slack上に流れてくるお問い合わせのイメージ さらに、2週間に1度のMTGで各チームからの共有時間があるので、普段お問い合わせ対応を行っているOperationチームから、お問い合わせ対応の中でのプロダクトに対する困り事やこういう問い合わせが多かった。という情報共有をもらうこともあります。 以下のように、Operationチーム内でLookerダッシュボードを使って可視化も行っているため、数の増減や割合なども理解しやすく共有してもらっています。 Operationチームの発表時に使っていたNotionのキャプチャ OperationチームのLooker活用事例に関しては、ぜひ以下のPodcastも合わせてお聞きください。 https://open.spotify.com/episode/7wD9QCv6imYPOGsGIuvSTU?si=eA8ENSswQBWoGrOFkaz7fg このような形でBASE BANKチームのフロントエンドエンジニアはOperationチームのメンバーとデザイナーチームのメンバーと一緒にお問い合わせを基にUIの改善に取り組んでいます。 課題解決のための手段としてChrome DevToolsを活用しよう 2つ目のアンテナを張っていることは、 エンジニアと他職種のチームメンバーのコミュニケーションコストを下げるための手法について です。 上述の「お問い合わせ」があった際のUI改善やプロダクトの機能開発をサクサクできるように、メンバー間のコミュニケーションコストが下がることで、意思決定の精度とスピードが上がりより早くユーザーに価値提供をすることが出来るようになります。 これを実現するための具体的な手段として Chrome DevToolsの活用 を推していて、ステージング環境などで実際のUIを表示し、Chrome DevToolsでHTMLやCSSをサクッと変更して画面キャプチャするだけで事足りることも多々あります。 実際にあったやり取りだと、以下のようなものがあります。 この事例の他にもGoogle MeetにデザイナーとPdMの方に集まってもらい、画面共有をしながらChrome DevTools上でHTMLやCSSのスタイルを変更して実装方針をああでもないこうでもない。という話をしたこともあります。 その他、ちょっとした文言の修正の場合は document.designMode = ‘on’ （ 詳しい解説はこちらのW3Schoolで実際に触ってみる のがわかりやすいです）をパッと設定して画面キャプチャすることもよくあります。 こういったUIの検討時に文章ではなく視覚的に理解しやすいものを作るために、フロントエンドエンジニアが「Figmaを使いこなしてデザインファイル自体をサッと変更してキャプチャを作る」という選択肢もあります。 ただ、個人的にはChrome DevToolsがフロントエンドエンジニアにとっての最高のIDEだと思っていますし、ビルド後のDOM構造がどうなっているのか把握しておくことで得られるメリットもあると思っているので、この方法を活用することをおすすめしています。 Chrome DevToolsについてより詳しく知りたくなった方はぜひ、 公式Docs を眺めてみてもらえればと思います。 時々、 新機能ニュースページ を眺めると「ｴｯｯ、こんな便利な機能増えてたの！」とお宝を見つけたような気分になれるのでとってもおすすめです。 おわりに 以上がBASE BANKチームに異動して考えるようになった、フロントエンドエンジニアとして出来ること・やるといいと思ったことのご紹介でした。 Operationチームとの協業の仕方はBASE BANKチームに異動してから大きく変わったなと感じますし、BASE BANKチームが担当しているのはまだまだ探索フェーズの機能・プロダクトがたくさんなので、どんどんリリースしてどんどんフィードバックを受け取って改善を進めていく感覚が強いです。 もし、こんなことを考えている私やBASE BANKチームに興味を持たれたらぜひ採用ページからお声がけください！（↓のページの募集職種一覧から、BASE BANKチームでフィルタリングしてもらうと積極採用中であることが伝わるかと思います！） binc.jp また、いきなり仰々しいカジュ面はちょっとアレだし、がっちゃんとは個人的に話してみたいぞ！という方はPittaやX（旧Twitter）のリプ・DMなどでお声がけください🙋 https://pitta.me/matches/PDWMyhvOjUOy https://x.com/gatchan0807

こんにちは！ BASE BANK Divisionの 松雪 です。 8/5に Welcome Fintech Community #2を開催しました。 お盆を挟んでドタバタしていたら3週間ほど経ってしまいましたが、今回も大盛況だったのでその様子をお届けします！ Welcome Fintech Communityについて コミュニティ立ち上げの経緯はこちらに記載しているのでぜひご覧ください。 devblog.thebase.in 6/20に開催した第1回がありがたいことに大反響だったため、鉄は熱いうちに打て!ということで1ヶ月半ほどで第2回を開催しました。 今回は第1回の懇親会で是非次があれば話したい! と意思表明してくださっていたSTORESさんとMIXIさんにお声がけし、公募LTと合わせて5人にご登壇いただきました。 また今回は初の試みとして、エンジニア転職サービスForkwellを運営するGroovesさんに飲食スポンサーをしていただきました! この場を借りて改めてお礼申し上げます。ありがとうございました! 当日の様子 今回はLT後の懇親会へスムーズに移行できるよう、アイランド形式のテーブル配置に。 第1回に引き続き司会のBASE 柳川さん Forkwell のしもおかさん！飲食サポーターありがとうございました！！ LT LT一発目は 株式会社MIXI から浅見さん。 ウォレットサービスとしてのMIXI Mは知っていましたが、ID、認証基盤としても展開しているのは個人的には初耳でした。 確かに決済サービスは本人確認などユーザーと強く紐づいているので、それを認証基盤として切り出して提供するというのは意外と思いつかなかったなあと新たな発見がありました。 続いて STORES株式会社 からSTORES 決済 に関わっていらっしゃる西村さん。 決済時の基本的な座組の話や、STORES決済を使った決済時の電文の経路についてお話しいただきました。 電文の経路は一般的なカード決済とは少し違う経路で問い合わせが行われており、カード決済などに詳しい参加者からは”そんなことできるの??”という声も上がっていました。 3人目は クラスメソッド株式会社 の和田さん。 DevelopersIOにはいつも助けられていますありがとうございます。 AWSと PCI DSS についてのお話で、責任共有モデルからReserved InstancesやSavings Plansまで、決済だけでなくAWS上で事業を行うすべての方に必要な情報をたくさん共有いただきました。 4人目は 株式会社dinii の角田さん。 diniiさんはモバイルオーダーだけでなくPOSやオンライン決済機能もあるため、決済サーバやPOSサーバ間でどのようにデータの整合性を保ちながら決済を実現するかなど、飲食店でのオペレーションならではの苦労するポイントなどがたくさんあるんだなととても勉強になりました。 最後に 株式会社LayerX からken5scalさん。 金融庁が”金融分野におけるサイバーセキュリティに関する ガイドライン（案） ”というものを公開していたようで、その中から所感や我々fintechに関わる人間にも関係がありそうな内容をピックアップしてくださりました。 ルールに従うだけでなくルールを一緒に作っていくために、パブリックコメントで意見を出そう！というメッセージが参加者の皆さんにもとても刺さっていたようです。 懇親会 懇親会も前回に引き続き大盛況！ (盛り上がりすぎて写真撮影を完全に忘れていました・・・) 事前に懇親会に移行しやすいようなテーブル配置にしたからかな?と思いつつ、もっといい配置や進め方はありそうだなと感じる場面もあったので、このあたりはこれからも色々と試行錯誤しながら参加者のみなさんが盛り上がりやすい場の設計をしていきます！ おわりに 改めて、今回ご参加いただいた皆様ありがとうございました！ そして！！！！第3回の開催も決定しました！10~11月ごろを予定しています。 また追って開催日やconnpassの公開など行っていきますので、ぜひコミュニティメンバーになっておいてください！ https://welcome-fintech.connpass.com ではまた、第3回で初参加したい方もリピーターの方もお待ちしております！！

はじめに こんにちは。ProductDev FeatureDev3 でエンジニアをしています、 endu です。 先日、自分が所属するチームで「良いコード／悪いコードで学ぶ設計入門」という本を題材に輪読会を開催しました。 gihyo.jp この記事では、「良いコード/悪いコードで学ぶ設計入門」を読もうと思った背景や、チームで実際に行った輪読会の進め方、輪読会を通じて得た学びについて共有できればと思います。 輪読会を開催した背景について BASEではショップを独自にカスタマイズする拡張機能として「Apps」を提供しています。 自分が所属するチームでは特に「 Google商品連携・広告 App 」や「 Instagram広告App 」、「 Instagram 販売App 」、「 TikTok商品連携・広告 」など、主にSNS Apps周りの保守や機能改善を行っております。 当然GoogleやMeta側から提供しているAPIのアップデートがあるので、アップデートの対応をおこなったり、お問い合わせ起因での細かい修正も発生します。 これらのSNS AppsはBASEでも歴史が長く、チームに配属したばかりの頃は全体の仕様が把握できてない事もあり、既に書かれているコードを参考にして追加したものの、いまいち良いコードをかけているかの自信がありませんでした。 そうこうしている内に、チーム内で輪読会を開催する話が上がったのと、自分が書いたコードに対してモヤモヤがあったので、「良いコードとはなにか? 悪いコードはなにか?」を考える機会を作る為にこちらの本を提案し、輪読会を開催する事になりました。 輪読会の進め方について 今回、私達のチームでは以下のフォーマットに沿って進めました。 章や項など、書籍や文書の構成単位毎に担当者を割り振り分ける。 担当者は担当分のページを読み、必要に応じて調査などして理解した上で要約・感想をNotionに記述する。 輪読会の開催日に担当者は自分が読んだ分の要約・感想などを発表する。 輪読会参加者は担当者の発表を聞き、質問を投げたり、担当者と自身の解釈の差を述べるなどして議論し、理解を深める 次回の予定と担当者の確認をして終了。 なお、担当者以外の方の予習は任意で、基本的には担当者の方が記事を読んで要約して発表するスタイルで輪読会は開催しました。 輪読会を通じた学びについて まずこの本が何を目的に書かれたか?については「15章 設計の意義と設計の向き合い方」で以下のように著者は書いています。 本書はソフトウェア開発上の悪魔を退治する設計方法を記述したものです。悪魔はさまざまな悪事を働きます。デバッグ時や仕様変更時、どのロジックが影響しているのか影響の把握を困難にさせます。また、仕様変更時に修正漏れが起こりやすく、バグが発生するなど、正確な動作ができるようになるまで時間を浪費させます。こうした悪魔の性質と最も関係がありそうな品質特性はどれでしょうか。保守性をみてください。「システムを修正する有効性や効率度合い」とありますね。そうです、本書で取り扱っているのは保守性に関係する設計です。 このように1章から~17章まではほぼ一環して、この保守性に関連する手法が紹介されています 第1章の「悪しき構造の弊害を知覚する」と第2章の「設計の初歩」はこの本の導入部として読みやすいです。良い設計を行うにはまず、悪い設計とはなにか?を考えて自分の中で基準を持つ必要があります。 そういった意味で最初に1章で悪いコードとはなにかの事例を学び、2章では「設計の初歩」として、意図した名前付けを使う、理解を困難にする条件分岐のネストは避けるなど、基本的な手法が紹介されています。 第3章「 クラス設計 ―すべてにつながる設計の基盤―」からクラス設計の話が始まるのですが、ここの章から少しづつ「自分達のコードどうなのか?」という話題がチームメンバー内で出てきました。実際にここで書かれているコード通りにできているのか?だったり、他のチームや過去の経験談などの話題などを出しながらチーム内で設計について、議論ができて良かったです。 また個人的には第6章「条件分岐 ―迷宮化した分岐処理を解きほぐす技法―」では、switch caseを使わずにinterfaceを使い、ストラテジーパターンで処理を分ける方法についてはサンプルコードが提示されていて、わかりやかったです。 6章以降についても、より実践的なテクニックや、設計の向き合い方についても書かれていますが気になる方はぜひ本誌を手に取って読んでみください! 輪読会後に得た良い体験としては、実際に業務の会話で「これって本の例で書かれていた悪いパターンでは?」という話があがって、実装を変更する機会がありました。 「良いコード/悪いコードで学ぶ設計入門」の輪読会を開催した事で、少しづづですが良いコードを書く自信が持てたと思います。 輪読会に参加したメンバーからのコメント 輪読会に参加メンバーからも感想をいただいたのでご紹介します! 保守を観点に実例を交えながら実践的な形でまとめられていたので、開発やレビューについて見直すいい機会となりました。メンバーとも体験談を交えながら話し合うことができたので有意義な時間だっと思いました。 わかっている ”つもり” になっているようなことも多く出てきて、読みながら再認識（と少し反省、、）できてとてもよかったです。チームメンバーと設計の良し悪しの目線を揃えられる点でもとても有用だったと思っています。参加できてよかったです。 サンプルコードや具体的な事例が豊富で、身の覚えのあるものも多く、学びがありました。各メンバーの知見も得られる、良い機会にもなりました。 この本の輪読会は通算2回目でしたが1度目で吸収しきれなかった部分やその他思い出すいい機会になったため更に知識が深まりました。また、過去の事例や「この場合どうする？」みたいな議論も毎回挟めれたので有意義な時間でした おわりに 「良いコード、悪いコードで学ぶ設計入門」の輪読会を通じ、チーム内で議論しながら設計について学べる機会ができました。 この本を読んでからは自分の中で良い設計、悪い設計とは何か?の基準を持てるようになり、リファクタリングする際も選択肢が増えました。 今後の業務でもこの本にかかれていた内容を元に良い設計を作っていきたいと思います! 最後に宣伝ですが、BASE ではエンジニアを採用中です! 今回のような輪読会の他にも社内LT会など開催されているので興味がある方は下記の紹介資料や、採用情報やもぜひご覧ください! speakerdeck.com binc.jp

はじめに 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環境にレプリケーションしています。 具体的には、本番環境にあるレプリカDBをDMSタスクのソースに指定し、DS環境で使用するDBへと同期を行っています。 また、DMSで同期したDBをさらにソースとして指定し、DMSの変更検知（CDC）によって取得した差分をAmaon MSKに流しています。これによって特定のテーブルにデータが挿入/更新されたというイベントを取得することができ、それをトリガーにworkerで他の処理を行っています。そういったworkerや、定期実行されるバッチによる処理結果を保存しておくためのDBも同じDBクラスター内に存在しています。 今回アップグレード対象となったのは、図で赤枠で示した「DS DBクラスタ」部分になります。 事前検証 DSチームのDB（以下、DS DB）では上述した通り、DMSを用いてプロダクト側のデータをレプリケーションさせています。DSチームの方がアップグレードを早めに実施するスケジュールで動いていたため、メジャーバージョン単位でのバージョン差異があってもDMSによる同期が可能なのかを事前に検証しました。できない場合はアップグレードのタイミングをプロダクト側と合わせる必要があるためです。 検証方法としては3つのDBクラスターA（MySQL5.7）, B（MySQL5.7）, C（MySQL8.0）を用意し、以下のような形でDMS連携を行いました。 その後、BをMySQL8.0にアップグレードさせることで2つの事象を同時に見ることができます。 A（MySQL5.7）→B（MySQL8.0）: DMS連携先（DS DB）がアップグレードした時の挙動 ここについては特に問題は発生しませんでした B（MySQL5.7）→C（MySQL8.0）: DMS連携元（プロダクト側のDB）がアップグレードした時の挙動 BをMySQL8.0にアップグレードさせると、B→CへのDMSタスクが失敗していました。 DMS連携の際にONにしておく必要のあるシステム変数log_binがOFFになっていたためでした。 こちら を参考に再起動したところ、エラーは解消されました。 一部エラーは発生しましたが、メジャーバージョン単位でのバージョン差異があってもDMS連携は問題ないと判断しました。またDMS連携元（プロダクト側のDB）をアップグレードする際にはlog_binの値に注意する必要があることも分かりました。 アップグレード方法の検討 Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード を参考に以下3つの選択肢からアップグレード方法を検討しました。 インプレースアップグレード ブルー/グリーンデプロイ スナップショットからの復元 アップグレード後に問題が発生しても、旧バージョンに戻す古いクラスターに切り替えることが可能な点やダウンタイムを最小限に抑えられる点からブルー/グリーンデプロイを選択しました。 ブルー/グリーンデプロイは、ブルー環境（稼働中のDB）とは別でグリーン環境（MySQL8.0にアップグレードされたDB）を構築しておき、任意のタイミングで本番環境をブルー環境からグリーン環境に切り替えるものです。データはブルー環境からグリーン環境にレプリケーションされているため、差分が生じることはありません。 次にAWSのブルー/グリーンデプロイ機能を使うか、グリーン環境をDMSを用いて自前で構築するかの検討を行いました。後者は準備に時間がかかるのですが、AWSのブルー/グリーンデプロイ機能でロールバックが行えるか、など不明な点が当初いくつかあり、反面DMSの環境構築に関しては既に知見がありあまり困ることがなさそうだったので自前で構築することにしました。 DMSを用いたグリーン環境の構築 DMSを用いてブルー環境のデータをレプリケーションする準備をしていましたが、その作業を行なっていくうちに一つの課題にぶつかりました。 カラムのデータサイズが大きすぎるとDMSタスクがタイムアウトになる まず、DMSでDS DBのデータをグリーン環境に同期して、全く同じ状態のDBを構築することにしました。 DS DBには、プロダクトからDMSで同期しているテーブルに加えて、DSチームで動かしているリソースが新規保存・更新を行なっているDBやテーブルが含まれています。このテーブルの一部で、 MEDIUMTEXT など大きめのデータ（LOB: ラージバイナリオブジェクト）を保存しているカラムが存在しています。 DMSでこれらのLOB列を含むテーブルのレプリケーションを行う際、通常のバイナリログによる同期ではなく、選択可能なLOBモードによる処理方法を適用することになります。 AWS DMS タスクでのソースデータベースの LOB サポートの設定 グリーン環境へレプリケーションを行うDMSタスクを実行していると、以下のようなエラーが発生しました。 Table ' db_test ' . ' table_test ' was errored/suspended (subtask 1 thread 1 ). Failed (retcode -1 ) to execute statement; RetCode: SQL_ERROR SqlState: HY000 NativeError: 3024 Message: [MySQL][ODBC 8.0 (w) Driver][mysqld -5.7 . 12 - log ]Query execution was interrupted, maximum statement execution time exceeded (replicationtask.c: 3066 ) LOB列に対しては、ステートメントを発行して別途データを取得するようなのですが、そこでタイムアウトが発生したものかと思われます。 AWSにてサポートケースを作成し、状況を共有しつつ以下のような項目を実施しました。 自主的に検証（DMSタスク設定） CommitRate を1000から100に TransactionConsistencyTimeout を60から600に HistoryTimeslotInMinutes を5から60に サポートから共有を受け実施（DMSエンドポイント設定） ExecuteTimeout を60から3600に しかしこれらの変更を行なっても改善がみられませんでした。 続けていくつかの対応方針も提供していただいたのですが、これ以上時間をかけて対策を進めるより、AWSのブルー/グリーンデプロイ機能を試した方が良いかもと思う点がいくつか発生してきました。 DS DBのデータは小さくないので、DMSによる同期もかなり時間がかかることが想定される 自前でブルー/グリーンデプロイを行うとしても、書き込みを行なっているリソースがあるために、データの不整合なくロールバックを行うことはほぼ不可能 今後もアップグレードの機会はあるので、公式機能で楽に対応できることがわかっていればそれに越したことはない ブルー/グリーンデプロイ機能でも想定しているテストや切り戻しができそう 以上からDMSを用いたブルー/グリーンデプロイは断念し、AWSのブルー/グリーンデプロイ機能を使う方針に変更しました。 AWSブルー/グリーンデプロイ 事前確認 準備については ブルー/グリーンデプロイの作成 を参考に進めていきました。ブルー/グリーンデプロイ作成時に考慮すべき点を列挙しておきます。 ブルー/グリーンデプロイでサポートされていない機能を利用しているか 以下の機能はブルー/グリーンデプロイでサポートされていないため、利用している場合は一時的に接続を切るなどの検討が必要になります。DS DBでは利用していなかったため特に困ることはありませんでした。 Amazon RDS Proxy カスケードリードレプリカ クロスリージョンリードレプリカ AWS CloudFormation マルチ AZ DB クラスターのデプロイ ブルー環境のDBクラスターのbinary loggingがONになっているか ブルー環境からグリーン環境へのレプリケーションを行うためにバイナリログが必要になるため、パラメータグループの binlog_format を確認する必要があります。フォーマットは複数あり、どれでもレプリケーションできるそうですが推奨は ROW でした。DS DBでは元々、DMSを利用している点から元々、 ROW に設定していたのでこちらも特に問題なかったです。 ブルー/グリーンデプロイの作成 作成自体はグリーン環境のエンジンバージョンの設定や事前に作成しておいたパラメータグループを指定するだけだったので簡単でした。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-creating.html#blue-green-deployments-creating-preparing-mysql 作成開始後、まずブルー環境のDBクラスターを複製後にアップグレードをしてグリーン環境を構築します。複製自体は数十分程度で終わったのですが、アップグレード時にエラーになりました。 Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the upgrade-prechecks.log file upgrade-prechecks.log ファイルを確認したところ、とあるテーブルのパーティションをアップグレードする必要があるようです。 Partitioning upgrade required. Please dump /reload to fix it or do: ALTER TABLE `database`.` table ` UPGRADE PARTITIONING " 対象のテーブルはDSチームで現在利用していないものだったため、今回は削除することにしましたが必要な場合はエラーの案内に従って更新をかけることで解消できたと思います。 再度作成作業を行い、グリーン環境の構築が完了しました。構築する時間は大体1時間程度でした。 検証 グリーン環境の構築が終わったため、DS DB周りで動いているバッチやAPIを動かしてみて、動作に問題がないかできる限り確認を行いました。 ブルー/グリーンデプロイ機能では、グリーン環境構築後にグリーン環境に接続を行えるエンドポイントが作成されます（データはブルー環境のものが論理レプリケーションされており、基本的に同じものを扱える）。これにより、テストしたいリソースの向き先をグリーンのエンドポイントに向けて実行してみることで、切り替え後の問題が発生しないかを事前に確認することができます。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html 確認の中で、書き込み処理のテストを行おうとしたところ、パラメータグループのread_onlyは0になっているが、グリーン環境側ではONの状態になっていることに気づきました。 パラメータグループ MySQL MySQL [(none)]> show variables like ' read_only ' ; + ---------------+-------+ | Variable_name | Value | + ---------------+-------+ | read_only | ON | + ---------------+-------+ AWSのドキュメント で、グリーン環境は読み取り専用に保つことを勧めているため、このような差異が生まれているのかと推測しています。なお、スイッチオーバーした際にはread_onlyパラメータはOFFになっていましたので、気にする必要があるのはテスト時のみでした。 テスト中は、グリーン環境のデータベースを読み取り専用に保つことをお勧めします。グリーン環境ではレプリケーションの競合が発生する可能性があるため、書き込み操作を有効にする場合は注意してください。また、スイッチオーバー後に本稼働データベースに意図しないデータが発生する可能性もあります。Aurora MySQL の書き込み操作を有効にするには、 read_only  パラメータを  0  に設定し、DB インスタンスを再起動します。 実施 メンテナンス当日、DMS, CDCタスクを停止後にグリーン環境への切り替えを実施しました。ダウンタイムは3分程度で終わり、この切り替え自体は特に問題が発生しませんでした。 ただ、DMS、CDCタスクを再開した後、DS DB→Amazon MSKへのCDCタスクがエラーとなっていました。確認したところ、log_binがOFFになっていたことがわかりました。 show global variables like " log_bin " ; + ---------------+-------+ | Variable_name | Value | + ---------------+-------+ | log_bin | OFF | + ---------------+-------+ DMSの事前検証の時点で同様の現象が起きていたため、ライターインスタンスを再起動してみたところ、ライターインスタンスでlog_bin=ONになってCDCタスクも動くようになりました。再起動自体は1分程度で完了しました。 おわりに AWSのブルー/グリーンデプロイ機能は、パラメータ周りには少し悩まされましたが大した問題にはならなかったですし、簡単に利用できて実施もすぐに終えられたので非常によかったです。今後のDS DB関連のメンテナンス方法において有力な候補になると思いました。 最後となりますが、弊社ではデータエンジニアを募集しています。ご興味のある方は気軽にご応募ください！ open.talentio.com

welcome fintech communityのバナー。かっこいい！ こんにちは！ BASE BANK Divisionの松雪です。 今回、金融決済の技術領域を中心としたコミュニティを立ち上げ、6月20日にイベントを初開催しました。 その模様をお届けします。 Welcome Fintech Communityとは? 特定の技術や職能に関するコミュニティは数多くありますがfintechに関するコミュニティは少なく、fintech領域を盛り上げていくために知見やお悩みの共有ができるようもっとオープンなコミュニティがほしいなと感じていました。 そんなとき、EMゆるミートアップでスマートバンク社の 三谷さん と出会い、「fintech界隈で集まってもっと色んな話したいよね？？？」と盛り上がった結果このコミュニティを立ち上げることにしました。 welcome-fintech.connpass.com 当日の様子 LT 司会の柳川さん。さすが盛り上げ上手。 申し込みについては、ありがたいことに40人枠が一時いっぱいになるほどの盛況！ こういうイベントは申込み人数に対して6~70%くらい来場してくだされば御の字と言われていますが、80%近い方にご来場いただき、熱量の高さを感じました。 最初はBASE BANKから、根本さんの “BASEカードから見る決済サービス"。 カード決済の基本的な仕組みやそれを実現するための「BASEカード」 のシステム構成、さらにはキャンペーンなどの施策をどう実現するか?など具体的な話までしてもらいました。 決済パターンが本当に多様で実際にリクエストが来るまで存在自体知らないものもたまに発生するという話に、カード決済に関わっていらっしゃる参加者の方々が深く頷いており、皆さん苦労されているんだな・・・と思いました。 BASE BANKの根本さん speakerdeck.com 次に株式会社スマートバンクのCTO 堀井さん から”カード発行会社(イシュア)を支えるシステム解説”というタイトルで「B/43」のアーキテクチャについて発表いただきました。 イシュアという立場では「BASEカード」と同じですが、より深くVISAの決済ネットワークと接続しているためPCI DSSというセキュリティ基準をクリアする必要があり、そのためにどのような技術選定、アーキテクチャ構築を行ってきたか赤裸々に発表してくださいました。プリペイドカードのプロダクトを立ち上げる機会がもしあれば必読の資料です！！ スマートバンクの堀井さん speakerdeck.com 最後にPAY株式会社からクリスさん。 PAY社でもPCI DSSの基準をクリアするための様々な対応を行っているのですが、今年実際に発生した対応事案についてサスペンスのごとく追体験していくような発表をしてもらいました。 詳細は是非資料を見てみなさんも追体験していただきたいですが、問題を特定し、無事解決したときには会場からお〜と歓声が上がっており、会場が一体感に包まれていました。 PAYのクリスさん speakerdeck.com パネルディスカッション パネルディスカッションでは、事前に用意していたテーマとXに投稿いただいた質問を拾いながら進めていきました。 決済の確定やキャンセルを考慮したキャンペーン予算設定の質問や、PCI DSSを考慮したシステム分割に付いての考察など、明らかにfintech経験者からの質問だ！という内容もあり、大いに盛り上がりを見せました。 パネルディスカッションの様子 懇親会 LTやパネルディスカッションの時間が足りなかったのか、懇親会でも各方から決済や送金、PCI DSSなど様々な決済談義が聞こえ、非常に盛り上がっていました。 次こういうテーマで話したい！という声や次回はいつやるんですか？？？など早速次回開催の要望をいただくなど参加してくださった皆さんの熱量が最初から最後まで高く、このコミュニティを立ち上げた意味があったなあと非常にありがたかったです。 懇親会の様子 おわりに 正直ある程度需要はあるだろうなとは思っていたものの、想定以上の盛り上がりを見せ、今後も継続してこのコミュニティを育てていきたい！と思えるイベントになりました。 当日の様子もXのハッシュタグを追うとさらにわかりやすいかと思います。是非ご覧になってみてください。 https://x.com/hashtag/welcome_fintech 最後に、この場を借りて共済してくださったスマートバンクさん、そしてご参加の皆さん双方に感謝申し上げます。本当にありがとうございました！ まだ未定ですが、第2回以降も開催したいと思っているので、ぜひご参加ください！

こんにちは。BASE BANKです。 先週BASE BANKメンバーの登壇やイベント参加が偶然重なったため、今週は実質イベントレポウィークとなっております。 今回は去る6月21, 22日に開催されたスクラムフェス大阪2024での登壇についてコメントをお届けします！ スクラムフェス大阪2024 今回参加したスクラムフェス大阪は、オンライン開催ではありますが大阪をはじめとした各サテライト会場が存在し、トラックごとに各会場の名前がつけられていました。 そのため、スクラムフェス”大阪”の”仙台”トラックだが”虎ノ門”会場から登壇など、なかなかハイコンテキストな状態になっている人もおり、ユニークでそれもまた話の種となっていました。 ”ズームイン”と銘打って各会場の模様を中継したりとオンラインならではの交流もありつつ、各会場ごとにもワークショップや懇親会も大いに盛り上がるなど、オンラインとオフラインの両方のメリットを最大限活かした場つくりがされていました。 スクラムフェスに関わるみなさんのイベント運営スキルの高さを肌で感じることができ、とても学びが多く楽しかったです。 今回のセッション BASE BANKからは松雪( @applepine1125 )と柳川( @gimupop )の2名が登壇しました。ちなみに2人とも今回の登壇がスクラムフェス初参加でした！ 柳川 -「アジャイルソフトウェア開発宣言」を実践するために事業責任者になる話 Scrum Fest Osaka 2024 - 「アジャイルソフトウェア開発宣言」を実践するために事業責任者になる話 | ConfEngine - Conference Platform 登壇者コメント XP祭りへの参加経験はありましたが、アジャイルコミュニティへの参加は今回がほぼ初めてでした。 リモート配信の仕組みが整っておりサテライト会場とオンラインを同時に繋がっていました。人の顔が見える場所を用意していただいたので、非常に発表しやすかったです。空気感もとても温かく、45分間虚空に向かって発表し続けるのは辛いなーと思っている中で非常に助かりました。オンラインなのに集まれて、終了後飲み会ができる体験が最高でした。品川葛飾トラックラブ。 今回の私の発表はWebサービスを作るならプロダクトマネージャーは事業責任者になれという、脳筋的な圧強めメッセージなんですが、資料読んでいただけると納得いただける・・・はず！ BASE BANKのチーム作りの背景が見える発表でもあると思います。 動画も後日出るそうなのでお楽しみにお待ちいただけますと。 松雪 - 新規事業立ち上げ、グロースできちんと"ディスカバリー"し続けられるアジャイル組織の作り方 Scrum Fest Osaka 2024 - 新規事業立ち上げ、グロースできちんと"ディスカバリー"し続けられるアジャイル組織の作り方 | ConfEngine - Conference Platform speakerdeck.com 登壇者コメント 今回スクラムフェス大阪にてスクラムフェス自体に初参加、初登壇させていただきました。 はじめはどういった雰囲気かわからなかったのですが、他の方々の発表から得るものが非常に多かったのはもちろん、登壇者だけでなく参加者同士でも相互にコミュニケーションをとる場が設けられていたりと、学びを最大化するための工夫が随所に施されており非常に器の大きいコミュニティだなあと感じました。 自分は時間の都合で懇親会には参加できなかったのですが、参加者用のDiscordに各地の懇親会の楽しそうな写真が上がっており、次は絶対懇親会まで参加するぞ・・・！と心に決めました。 発表では、ただスピーディにアウトプットするだけでなく、ちゃんと仮説検証のサイクルを回し続けられるような組織づくりが大事だよ！という話をしました。 新規事業立ち上げ、グロース時期はどうしてもアウトプットにばかり目が行きがちかもしれませんが、そういう状況こそ丁寧かつ素早くディスカバリーサイクルを回し、”正しい”プロダクトを作り続けることが何より大事だと思っているので、同じような状況の方がいらっしゃればぜひ一事例として参考にしていただければと思っています。 おわりに どうやらオンラインとオフラインのハイブリッド形式での開催は今回が最後だったようで、次回以降はオフライン開催になるようです。 各会場の熱量も高く、いろんな地方でいろんな仲間と出会ってみたいと思ったので、今後もまた参加していきたいです！ 最後に宣伝ですが、BASE BANKでは今回発表したような事業づくり、組織づくりを一緒にやっていってくれる仲間を募集しています！ 技術、組織、事業、なんでもよいのでもしBASE BANKに興味を持ってくださった方がいたらぜひお話しましょう！お待ちしています！ open.talentio.com

はじめに BASE BANK Division で フルサイクルエンジニア をしている02 （ @cocoeyes02 ）です。 2024/06/22（土）に開催されたPHPカンファレンス福岡 2024に登壇しました。今回の記事では登壇についてのコメントと、会場の様子についてお届けします！ 今回のセッション 今回は15分枠での登壇です。 speakerdeck.com 02 @cocoeyes02 さんのトークがはじまっています❣️ #phpconfuk #hall_hz https://t.co/AFxNus3Zay pic.twitter.com/DyCkj3fD8D — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) 2024年6月22日 時間が許す限り、PHPUnit 11のアップデートについて話しました！ Ask the Speakerで聞いていると、前回のPHPUnit 10も含めPHPUnitのバージョンアップに苦労している方が多いように感じました。 最初は興味や登壇のネタになるという理由から始めたPHPUnitの学習でしたが、現在は将来の必要性を感じて取り組んでいます。今後も、翌年にリリースされるPHPUnit 12についてや、まだ話していないPHPUnit 10 / 11 の変更点など、ブログや登壇で話せればと思っています。 現地の様子 ここからは、現地の様子を一部お届けします！ オープニング オープニングは実行委員長の元気溢れる挨拶からスタートしました。 朝にも関わらず多くの人が参加しており、オープニングの時点でスタッフや参加者の熱量の高さを感じました。 #phpconfuk 2024、開幕です🎉 実行委員長 @BkNkbot のオープニングからスタート❣️ pic.twitter.com/WE182JzXOW — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) 2024年6月22日 自由に表現できるネームカード 参加者のネームカードは、自分で書いたり、属性シール（普段触っている技術や、ロール、熟練度など）を貼ったりと、自由に表現できるようになっていました。 どんなバックグラウンドやキャラクターの人が参加しているのか、ひと目でわかるようになっていて最初の話題を出しやすかったです。 ネームカードを書いたりシールを貼る場所の様子 対よろです（眠気で字がぐちゃってる） #phpconfuk pic.twitter.com/evxBil9LEl — 02 (@cocoeyes02) 2024年6月22日 スポンサーブースの様子 どのスポンサーブースも賑わっており、参加者同士のコミュニケーションで溢れかえっていました。 また、コーヒースポンサーによるコーヒー飲み放題や、福岡ならではのお菓子もいくつかおいており、福岡を満喫できるようなホスピタリティを感じました。 スポンサーブース周辺の様子 早速東京近辺に集中してる #phpconfuk pic.twitter.com/Sc8I3xetr9 — 02 (@cocoeyes02) 2024年6月22日 コーヒースポンサーが提供しているコーヒーと福岡ならではのお菓子 また、Ask the Speakerもこのスポンサーブース近辺で開催されました！ ＼CホールにてAsk the speaker 開催中🎙／ おかしょいさん @okashoi と、02さん @tadsan と、チャンさん @zosokh と、sora さん @_fs0414 と、とうださん @picopico_dev と、Kanon さん @samurai_se に質問したい方はCホールへ🏃 珈琲片手に、お気軽にお越しください☕ #phpconfuk pic.twitter.com/KFEBskbbqZ — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) 2024年6月22日 アンカンファレンスルーム アンカンファレンスも賑わっていました。最後の時間の「Round Tablle Session テーマ：学習どうしている？」に参加しましたが、 「どのくらい技術書を読んでる？」 「どういう目的で技術書を読んでいる？」 「どういう基準で技術書を選んでいる？」 といった技術書に関する質問について、各PHPerと自分の基準を共有したり、議論したことが面白かったです。 アンカンファレンスルームのタイムスケジュール クロージング クロージングが始まり、各情報の共有が行われました。PHPカンファレンス福岡 2024の参加者は約300人で、日本で開催されるPHPカンファレンスの中でも人数が多いカンファレンスだと再確認しました。 さらに、委員長から参加者のPHPカンファレンス参加歴（例えば、PHPカンファレンス福岡に初めて参加した人など）について尋ねる場面がありましたが、初めてPHPカンファレンスに参加した人や、技術カンファレンス自体に初めて参加した人が少なからずいることが印象的でした。 #phpconfuk 2024 、あっという間にクロージング😭 実行委員長 @BkNkbot のクロージングがスタートしました❣️ pic.twitter.com/no8lPwYsYm — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) 2024年6月22日 クロージング終了後には懇親会が始まり、色んなPHPerとご飯を食べて、お酒を飲みながら交流しました。 おわりに スタッフの方々にはお忙しいにも関わらず、多くの時間を準備に費やしていただいたと思います。この場を借りて御礼申し上げます。 初九州 / 初福岡 / 初飛行機を使って遠くへ出かけた技術カンファレンスだったので不安もありましたが、とても楽しめた素敵なカンファレンスでした。また開催されたら是非参加したいですね。 BASE / BASE BANKでは、絶賛PHPerを採用中です。下記の採用情報やカジュアル面談リンクからぜひご覧ください！ binc.jp open.talentio.com

はじめに BASE BANK Division で フルサイクルエンジニア をしている02（ @cocoeyes02 ）です。 AWS Summit Japan 2024のDay 1にオンサイトで参加してきたので、現地の様子をお届けします！ AWS Summit Japan 2024とは？ AWS Summit Japan 2024とは、2024/06/20〜2024/06/21に開催されたAmazon Web Services（以下AWS）を学ぶイベントです。 参加登録人数は5万人を超えるなど、文字通り日本最大のAWSを学ぶイベントになります。 aws.amazon.com 会場まで AWS Summit Japan 2024の会場は幕張メッセです。 お昼前にもかかわらず、入場まで人が並んでいました。日本最大のAWS学習イベントという表現は実にふさわしい、というほどの大盛況でした。 きたわね #AWSSummit pic.twitter.com/Aabz8OmdXd — 02 (@cocoeyes02) 2024年6月20日 AWS Summit Japan 2024会場への入場を待つ長蛇の列 AWS Summit Japan 2024会場入口の様子 会場全体の様子 入場してみると、たくさんの展示ブースやセッション会場が目の前に広がっていました。 エンタープライズサポートでやり取りのあったAWS SAの方々や、普段から接点のある方々にご挨拶するために、ブースを巡りました。会場は非常に広く、少し迷ってしまったのは内緒です。 入場してすぐのエリアを俯瞰して撮った様子 いくつかのセッションを聴講しましたが、その聴講環境が整っていると感じました。例えば、各セッション会場は大人数を収容でき、全席には登壇者のマイク音声をイヤホンで聞くためのレシーバーが用意されていました。 各セッションの会場を横から撮った様子 魅力的なコンテンツも盛りだくさん 全ては紹介しきれないですが、現地で体験したコンテンツを一部紹介します。 AWS Snowball Edgeデバイスを持ち上げてみた AWS Snowball Edgeデバイス の実物が展示されていたので、持ち上げさせていただきました。AWS Snowball Edgeデバイスは約20kgほどあり、両手でないと持ち上げられないほど重かったです。 AWS SnowballについてはAWS認定試験で学んだ程度の知識しか持っていなかったので、実際に触れることができるのは良い経験になりました。 snowball持ち上げさせてもらった #AWSSummit pic.twitter.com/oZRG9rHNvC — 02 (@cocoeyes02) 2024年6月20日 Chaos Kitty ゲーム形式でカオスエンジニアリングと可視化を学べる Chaos Kitty が展示されていました。ゲームモードはレジリエンスとセキュリティ、難易度はEasyとHardがあり、それぞれの復旧タイムランキングリストがありました。 私はレジリエンスモードのEasyをプレイさせてもらいましたが、擬似的に障害訓練をしているような感覚でした。自社向けのデモ環境があったら、楽しみながらインシデント対応力向上するきっかけになりそうだと思いました。 ゲーム形式でカオスエンジニアリングと可視化を学べるchaos kitty 面白かった！ #AWSSummit pic.twitter.com/Gv1y7KfhsX — 02 (@cocoeyes02) 2024年6月20日 Industry Zone このエリアでは、各業界ごとの最新の AWS ソリューションの紹介やデモが行われていました。私は流通小売消費財インダストリーに訪れ、EC体験の向上目指した様々な技術や機能を見てきました。 例えば、生成AIを使った商品説明文や商品背景画像の生成や、商品の細部を確認できる3D ホログラムディスプレイなどがありました。 Industry Zone：流通小売消費財インダストリーの様子 AWSで妄想してみた QuizKnock さんとのコラボ企画によるパネル展示です。「こんなことができたら良いのに」という妄想と、それを実現するための仕組み、そしてAWSアーキテクチャ図が描かれていました。 個人的には、SAの佐藤さんが妄想した「過去の自分へ相談するため、分身と会話できるようにする」がとてもエモくて試してみたいと感じる良いアイディアだと思いました。 「AWSで妄想してみた」のパネル展示の様子 SAの佐藤さんの妄想してみたパネル AWS 認定者ラウンジ AWS 認定試験 に合格した人専用のラウンジです。ラウンジ専用のWi-Fi SSIDとパスワード、飲み物、電源が提供されており、歩き疲れたり作業をしたい方に最適な場所となっていました。 特典として、合格した試験ごとにステッカーがもらえます。私は AWS Solution Architect Associate のステッカーをもらいました。 AWS 認定者ラウンジの様子 AWS Solution Architect Associateのステッカー 他にも紹介しきれないほどたくさんの魅力的なコンテンツ 他にも、AWSのサーバレスサービスで作られた Serverlesspresso や、 AWS DeepRacer Japan Championship Cup のレース会場などがありました！ AWSのサーバレスサービスで作られたServerlesspresso AWS DeepRacer Japan Championship Cupのレース会場 AWS DeepRacer Japan Championship Cupのサテライトディスプレイ おわりに スタッフや登壇者の方々にはお忙しいにも関わらず、多くの時間を準備に費やしていただいたと思います。この場を借りて御礼申し上げます。 セッションは2024/07/05まで見れるとのことなので、会場に直接行けなかった方もぜひご覧ください。 aws.amazon.com BASEでは、ロールや所属に関わらずAWSを使ってビジネスをリード、あるいはビジネスを守るエンジニアを募集しております。ご興味がある方は、ぜひ下記の採用情報のリンクをご覧ください！ binc.jp

はじめに Platform Group の久保田（ @ykbt13 ）です！ BASEではリアーキテクチャとしてバックエンドの既存機能を旧リポジトリから新リポジトリへ移行する作業を日々行っています。詳しく知りたい方はぜひこちらを参照してください。 www.youtube.com そんななか、BASEにおけるコア機能の1つである商品の発送機能の移行が行われました。しかしながら、コア機能であるがゆえに様々な改修が繰り返されて複雑化してしまった発送機能では移行前の動作を保証する術がテストのみでは不安があります。 そこで、リアーキテクチャを円滑に進めるべく、 本番環境上で 移行前後の処理を同時実行しデータベースの結果を比較することで動作の保証を行うツールを開発しました。 この記事では、同様にリアーキテクチャを進めている方々を対象に、そのツール（BASE内では通称DryRunと呼んでいますので以降DryRunと記載させていただきます）について、記載していきます。 TL;DR リアーキテクチャを手助けするツール DryRunを開発しました 実運用では部分的に本番環境を使ったDryRunを行いました DryRunを作っていくにあたって、いかに外部影響が少ないサンドボックスを作り上げることが重要なのかということに気づきました リファクタとリライト 少し本記事の内容から反れますが、背景につながりますので、リファクタとリライトについて触れていきます。 「 レガシーソフトウェア改善ガイド 」において、レガシーなソフトウェアを改善していく方法として リファクタ と リライト について触れられています。 www.shoeisha.co.jp リファクタリングは 外部から見た際に内部の挙動を変えずにソフトウェアを改善していく作業 であり、リライトは 同一機能を一から作り直す作業 に当たるものです。そのうえでリライトはリスクとコストのかかるものであり、 できるだけリファクタリングのみで改善ができないのか を検討したうえでリライトを選択すべきであるとしています。ただ逆説的に言うと、その リスクの保証やコスト面の解決ができれば 、リファクタリングでは得られなかったメリットを享受したうえで改善ができるのではないかとも言えるではないかと思っています。 リアーキテクチャをお手伝いするツール DryRun さてBASEにおいては、レガシーソフトウェアの改善としてリアーキテクチャが行われています。直近ではBASEにおけるコア機能である商品の発送機能の リライト によるリアーキテクチャが行われました。 なぜリファクタではなくリライトによる移行なのかというと、旧リポジトリでは MVC フレームワークでの密結合を前提としたモノリスですが、新リポジトリではDDDとクリーンアーキテクチャをベースとした疎結合なモジュラーモノリスであるため、アーキテクチャのパラダイムシフトが起きておりチームとしてリライトによる移行を選択したからです。 リライトによる大きなリスクの1つとして、 移行前後でのリグレッションリスク というものがあります。これはもちろんテストを通して保証することになりますが、 移行前の挙動と同義である というのを保証するのにテストのみでは限界があると思っています。そこで、移行前と移行後の更新処理に着目して、 データベースに対する永続化が同じものであるかどうか というものを確認することでその保証が行えるのではないかと考えました。これを実現するツールを作成しています。 DryRunの概要図 永続化を行っている箇所をある種の サンドボックス として提供して、移行前の旧機能と同時実行し 各処理で更新されたテーブルを比較すること で、データベースに対する永続化が同じものであるかどうかを比較するものとなっています。移行後のリライトされたコード視点ではサンドボックスであるかの区別はできず、 あたかも本来行うべき永続化処理を行っているかのように振る舞っている ため、DryRunという命名をしました。 かなり単純化されたものにはなりますが、擬似的なPHPのコードでDryRunの挙動を示しますと 移行元の擬似コード // 移行先の機能へのリクエスト function requestNewFeature(): NewResult { } // 更新された各データベースの比較 function compareDatabase(NewResult $newResult, OriginResult $originResult): CompareResult { } // 本来実行される移行元の処理 function executeOrigin(): void { if ($isDryRun === true) { $newResult = requestNewFeature(); } // 移行元の処理の実行 // DryRunであってもなくても必ず実行されます if ($isDryRun === true) { compareDatabase($newResult, $originResult) } } 移行先の擬似コード // データベースにアクセスする根本のinterface interface DatabaseAccess { } // DryRun中のデータベースアクセス class DryRunDatabaseAccess implements DatabaseAccess { } // 通常のデータベースアクセス class OriginDatabaseAccess implements DatabaseAccess { } function getDatabaseAccess(): DatabaseAccess { return $isDryRun == true ? new DryRunDatabaseAccess() : new OriginDatabaseAccess(); } // DryRun向けの処理結果を作成する function createDryRunResult(): DryRunResult { } // 本来実行される移行先の処理 function executeNewFeature(): void { $databaseAccess = getDatabaseAccess(); // 移行先の処理 // DryRun中だとしてもそうじゃないとしても挙動は変わりません。 return $isDryRun == true ? createDryRunResult() : $result } となります。実際には移行先環境ではDoctrineというORMを利用しており、DoctrineのDBコネクタをオーバライドしているのと、Ray.DiというDIフレームワークを利用して、擬似コードのような形でデータベースの向き先を変更しております。 仕組み上ある程度部品化されたコードが準備されているものの、移行対象の機能ごとにサンドボックスを一つ一つ作り上げる必要があるため、頻繁に使えるツールではありません。しかしながら、準備できさえすれば各種環境で動作させることが可能であり、移行元のコードが必ず実行されるようになるため、 本番環境でさえ も動作させることができます。 発送処理におけるDryRunの実運用 発送処理のリアーキテクチャは実働部隊が別途おりまして、DryRunはPlatformチームにて開発をいたしました。DryRunの開発が終わったタイミングで、リアーキテクチャされた発送処理に対して細かい単位（具体的には、支払い方法別）に分割して順次DryRunを適応していき、本番環境へのDryRunを実行していきました。 本番環境で動作させるということで安全に倒すように様々なガード処理を加えていたのですが、意外にもスムーズに動いてしまい、安心するとともにすごいものを作り出してしまったなあと開発当時に思っていた記憶があります。 また特に苦労した点なんですが、BASEのプロダクトの制限で個人情報を保存できる環境に制限があり、比較結果のログの出し方やサンドボックスに保存する際のマスク処理など、細かい単位での対応が必要なところに苦労いたしました。振り返ると1つの共通化したパーツを作り込んでいくというよりかは、泥臭く細かいサンドボックスを作り込んでいくという作業がメインだったなと思います。 そうして順次DryRunを稼働していく中で、実際に開発していただいていたエンジニアと協力して、見つかっていったバグなどの修正を加えてもらいました。 DryRunを利用する目的として、 データベースに対する永続化が同じものであるかどうか というものがありましたが、実運用していくうえで副次的にこのようなメリットも見つかっています。 実際に本番で運用されているデータという膨大なパターンのあるデータを使ってリリース前にコードを走らせることができた リライト中に旧機能への新規開発が行われていてその追従がきちんと行われているのかを確認できた これによって、細かいバグなどがリリースまでに解消でき、また本来の目的であるリグレッションへの対応も行えました。BASE内部の話になってしまいますが実際に開発を行ったエンジニアの方々お疲れ様でした。 反省点や課題点 実際に運用してみたうえでメリットだけはなく、デメリットもいくつか出てきてしまったのでそれらも振り返っておきます。 少し細かい点となってしまいますが、こういった課題がありました。 移行前後で同時に実行することによるパフォーマンスへの影響があった データベースへの書込は実際のRDBMSに書き込んでいたことにより、他のDryRun処理への影響が完全には分離できていなかった いかに 他への影響が少ないサンドボックスを作り込んでいくべきか という点が重要だったんだなと作ってみて改めて感じました。 特に今回、仕組みづくりに使える人員コストを加味して、PHPコード上（つまりはアプリケーションレイヤー）でサンドボックスを作り込んでいたのですが、そもそもデータベースから分けることやモック自体もHTTPサーバ化してPHPコード外で行うなど、各サンドボックスが得意な部分で分割して作り込んでいくというのが良かったのかもしれないと思っています。また、他のDryRun処理への影響という意味ではバージョニングがなされた形でデータベースへの書込みを行うことで回避できたなという反省点もあります。 このあたりはリアーキテクチャが続いていく中で、またDryRun機能を使う機会はあると思っているので、改善していければなと思っています。 おわりに 本記事では、リアーキテクチャをお手伝いするDryRunというツールについて紹介させてもらいました。 いざ作って動かしてみたときに想像していたよりもきちんと動作してしまい、本番環境でデバッグをするというとんでもないものを生み出してしまったなという感覚がありますが、個人的には作っていった中でいろいろと学びがありました。 BASEという環境において作られたものになるので、どこまで外部の方々に参考になるのかはわかりませんが、こういったリアーキテクチャの方法もあるんだなという一例として掲示させていただきます。 どこかでこんな方法で移行作業を行っているのだなと参考になるときが来れば幸いです。 binc.jp

はじめに BASE Feature Dev1 Group の cureseven です。 Google と米Yahoo が定めた 「メール送信者のガイドライン」 が、2024/06/01に対応の最終締め切りを迎えました。 BASE から送信しているプロモーションメールも対応が完了しましたので、対応する過程で起こったトピックを紹介します。 「メール送信者のガイドライン」とはなにか簡単に説明 1回でも月あたり 5,000件以上個人メールにメールを送信したことがあるドメインを持つ「一括送信者」は、以下の規定に則ってメールを送信する必要があります。 DMARC の対応 プロモーションメールには、購読解除ヘッダーが挿入されていること 迷惑メール率が 0.3%を超えないこと AWS が出している こちら の記事がスッキリしていて読みやすいです。 アプリケーション開発チームの私は、購読解除ヘッダーの挿入を主に担当しました。 迷惑メール率は幸運なことに 0.3%未満だったので、減らすための施策を行うことはありませんでした。 サービス関連のメールを全て洗い出す BASE ではシステムからメールを送信する以外にも、他社サービスを使っています。 いつも扱っているサービスのコードを見るだけでは見落としてしまいそうなメールもあったため、自分で登録している BASE アカウントに対して来たメールを見たり、さまざまなチームに問い合わせたりして、全体像を把握していきました。 BASE には、以下の種類のプロモーションメールがありました。 バッチで送信しているオーナー向けプロモーションメール 購入者がショップから受け取るメルマガ、再入荷自動通知、期間販売通知メール 営業チームが使っているメールサービス（SendGrid, kintone）から送信するメール 機械学習チームがショップ開設から最適なタイミングで送信するオーナー向け機能紹介メール（Amazon Pinpoint） 「プロモーションメール」なのか「トランザクションメール」なのか プロモーション メールとトランザクション メールの区別は、業界や適用される規制によって異なります。メールの性質は、Google ではなく受信者が判断します。迷惑メール率が高くなることを防ぐために、マーケティングやプロモーション関連のメール配信の登録をユーザーが簡単に解除できるようにすることを検討しましょう。また、メールを設計する際は、ユーザーを念頭に置くようにしてください。 メール送信者のガイドラインに関するよくある質問 より引用 とあるように、「プロモーションメール」が、業界によって異なる定義であること、判断するのはメールの受け取り手だという記載があります。 チームメンバーに意見を聞きながら、送信しているメールが「プロモーションメール」なのか「トランザクションメール」なのかを判断し分類していきました。 AWSとコミュニケーションを取りながらの実装 予約した時刻にメールを一括送信する機能には、Amazon SES を採用しています。Amazon SESの sendBulkEmailメソッド を使えば複数のメールを一括で送信できます。 AWS SDK for PHP 3.x のドキュメントに従って実装しましたが、sendBulkEMailの仕様通りに実装してもヘッダーが適応がされず困ったため、AWS に問い合わせながら進めました。 問い合わせたところ sendBulkEmail が、送信先ごとのヘッダー挿入に対応したのは 3.305.9 以降とのことで、バージョンアップをすることで解決しました。AWS SDK for PHP 3系ドキュメントに書いてあったため、3系だし大丈夫だろうと思っていました。 3.305.9 がリリースされたのは、メールの規定が開始する2週間前でした。 List-Unsubscribeで指定するURLの要件が厳しい ワンクリック購読解除APIは RFC8058 にしたがって実装する必要があり、以下があったことで、工数が膨らみました。 リクエストパラメータを使ってデータを送信しなければならない 個人を特定できるようなデータを送信してはならず、暗号化されていなければならない 既存のAPIを利用すれば購読解除ができないかと思っていましたが、メールクライアントからワンクリックで購読解除を行うために使う API はリクエストボディが使えなかったため、既存のAPI を修正する必要がありました。 また、リクエストパラメータに含めるハッシュ値の暗号化と、復号化の処理を新規で作成することになりました。 AWS のアカウントをまたいで、同じ方法で暗号化したハッシュ値を使って購読解除APIにリクエストする為、 AWS KMSを使った方法 を採用しました。 AWS KMS を利用して暗号化、復号化ができるようにインフラチームと相談しながら進めました。 開発環境で購読解除リンクが表示されないことがある 開発環境で利用しているドメインからのメールには、購読解除ヘッダーが適切に貼られていても購読解除リンクが出現しない事象がありました。 そのルールが明確に提示されておらず、調査に工数を取られてしまいました。そのため API を直接叩き、購読解除できること 購読解除ヘッダーが適切に貼られていること を確認した上でリリースしました。開発環境で購読解除リンクが表示されていなくとも、本番では全ての購読解除ヘッダーが挿入されているメールに購読解除リンクが表示されていました。 今後も対応されるように社内へ周知 エンジニア全体に、対応方法を周知しました。簡単に実装してもらえるように、以下を工夫しました。 暗号化、復号化のサービスを作り、それを利用するだけで API のパラメータに利用する hash を作成できるようにしました 各メール送信方法に対応するように、購読解除ヘッダーの挿入方法を記載しました BASE以外にも、BASE BANK, PayID チームなどがあります。広く周知しました 上記の詰まったこともドキュメントにし、開発者の対応が詰まらないようにしました おわりに プロモーションメールのワンクリック購読解除は、メールの受け取り手からすると、便利でいい機能ですね。 私のメールボックスも、プロモーションメールでいっぱいになっているので、ポチポチ解除してスッキリさせることができそうです。 規定の適応は開始されていますが、月あたり 5,000 件以上個人メールに送信していないドメインは迷惑メールに入るなどの処置が取られないため、未対応のシステムをお持ちの方もいらっしゃると思います。 今後対応することになった際参考にしていただけると嬉しいです。 binc.jp

はじめに こんにちは、バックエンドエンジニアのSakiです！バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL（InnoDB）についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しやすいと思います。 特別なindex、プライマリキーindex DBテーブルには、大抵プライマリキーindexというものが存在します。これはMySQLでは各テーブルに1つずつしか持つことができない特別なindexです。 プライマリキーのカラムで構成され、これはテーブルで必ずユニーク（一意）になります。 必要に応じて追加するセカンダリindex 検索効率を上げる、カラムに対する制約を追加するなど、さまざまな目的で必要に応じて追加するのがセカンダリindexです。言い換えると、プライマリキーindexではないindexは、全てセカンダリindexです。これは1カラムのみで構成されることもあれば、複数のカラムの複合で構成されることもよくあります。また、ユニークなindexにすることも、重複を許すこともできます。 複合indexが使えるシーン、使えないシーン 次のようなindexがあるとします。 単一カラムのindexであればプライマリキーindexと使用感は変わらないので、複合indexについて少し詳しくおさらいします。 // test table UNIQUE KEY `test_prefecture_city` (`prefecture`, `city`) // 都道府県と市の組み合わせ この時、次の2つのクエリを考えてみます。 SELECT * FROM test WHERE prefecture = ' Tokyo ' // 例 1 SELECT * FROM test WHERE city = ' Chiyoda ' // 例 2 ご存知の方はもちろん多いと思いますが、この場合、例1ではindexが効きますが、例2ではindexが効きません（使えません）。 なぜそうなるのかは、本の目次を例にするとわかりやすいです。大カテゴリとして都道府県の並びがあり、それぞれの都道府県の項目の中で市が並んでいるとしましょう。 東京 - 足立区 - 荒川区 ...（略） 千葉 - 千葉市 ...（略） さて、このような構成の目次から、都道府県を無視して（純粋に市だけで並べた場合の）例えば「あいうえお」順で市を探すことは理にかなっているでしょうか？無理があることがわかるかと思います。 したがって、複合indexを使用する場合、必ず左側のカラムから順に絞り込んでいけるクエリである必要があります。 必ずしもメリットばかりではない セカンダリindexはあればあるほど検索効率の向上に繋がりますが、反面、データのinsertやupdate時に全てのindexを更新する必要があるため、indexが多ければ多いほど書き込み処理の負荷が上がるというトレードオフの関係でもあります。 クエリの妥当性はexplainで評価する 実際に業務で使用するクエリは、例でよく見るクエリほど単純ではないことが多いです。実際にクエリが「きちんとindexを使える」かどうかは、 explain という機能を使って評価します。 explain の実行方法と結果の見方は記事がたくさんあるので、ここでは割愛します。 本題: explainだけじゃわからないことがある ここからがこの記事の本題です。 実は、 explain の結果がとても良いのに「なぜか遅い」クエリというものが存在します。これは、主に次のような状況が関係します（ Profile を見ても、「データ転送が遅い」というざっくりしたことしかわからなかったりする）。 テーブルが巨大（レコード数が多い） IN句で大量の条件を指定している（取りたいデータの対象が多い） SELECTで取りたいカラムのデータ取得コストがかかっている どういうことなのか、なぜ遅くなるのか、詳しく見てみましょう。 IN句は遅くなりやすい 不等号の範囲指定と違い、IN句（等価範囲）検索は、IN句に渡す値が増えれば増えるほど遅くなりやすい傾向があります。 例として、次のようなクエリを考えてみましょう。 // shipping_number = 配送番号 // shipping_numberのユニークindexがあるとする SELECT * FROM test WHERE shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0002 ' , ...（略） ); 等価範囲検索の性質上、単に「ここからここまで」という不等号的な検索方法ではなく、IN句の値ひとつひとつについて検索する必要があります。例の場合、 0000-0000-0000 〜 0000-0000-0002 という不等号的な範囲の検索では間の 0000-0000-0001 が含まれてしまいます。 テーブルが巨大であればあるほど、検索コストが大きくなりやすいことがわかります。 ただし、このようなクエリであったとしても、indexを適切に使用できているため、explain上ではかなりいい結果に見えるはずです。このクエリの問題点は、indexを使用することそのものにコストがかかっている、という点です。 取得したいカラムのデータ取得コストがかかる 次のクエリをご覧ください。 // prefecture = 都道府県 // city = 市 // zip_code = 郵便番号 // prefecture, cityの複合indexを持つとする SELECT prefecture, city, zip_code FROM test WHERE prefecture = ' Tokyo ' ; このクエリもまた、indexを適切に使用できるため、explainでは良い結果となります。しかし、テーブル自体が巨大であったり取得件数が多いと「なぜか遅い」ということになりやすいクエリです。 葉ノードという概念を考える ここで重要になるのは葉ノードという概念です。MySQLの使用しているindexの構造は木に例えられるのですが、そこから生えているデータなので「葉」というわけですね。 葉ノードには、カラムのデータが含まれています。冒頭のあたりで使用した、都道府県と市の目次の例を見てみましょう。 東京 - 足立区 - 荒川区 ...（略） 千葉 - 千葉市 ...（略） この例では、目次（index）で指定されている本のページ（テーブルデータ）にアクセスせずとも、都道府県と市の情報は目次の時点で手に入ることがわかります。東京 - 足立区というデータが存在することは目次を見ただけでわかる、ということです。 この情報が、すなわち葉ノードに含まれるデータだと考えてください。 indexは、そのindexに使用するカラムのデータを葉ノードに持っています。ただしプライマリキーindexだけは例外で、全てのカラムのデータを持っています（なので特別なindexなのです）。 ここで追加で「郵便番号」のデータを取得するとします。その場合目次には郵便番号の情報が書かれていないため、実際に目次の示すページを開き、そこから郵便番号を取得する必要があります。 セカンダリindexの使用時は、indexに含まれないカラムのデータを取得する際にテーブルデータへのアクセスが発生し、それがコストになる、と考えることができます（このコストは1件取得程度では誤差ですが、数万件取得、というような規模になってくると大きな差となります）。 解決方法 大量のIN句問題と取得カラム問題、2つの問題を提示しました。これらの解決策を考えてみましょう。 IN句問題: IN句の絞り込みの前に、絞れるだけ絞る 次のクエリをご覧ください。 // shipping_number = 配送番号 // prefecture = 都道府県 // prefecture, shipping_numberの複合ユニークindexがあるとする SELECT * FROM test WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...（略） ); 問題の提示に使用したクエリとの差は、indexと検索条件に都道府県を加えていることです。こうすることで、IN句の絞り込みの前に都道府県で絞り込んでくれるので、「テーブルの全てのレコード」に対してIN句の絞り込みを行うコストが、「都道府県分のレコードに対して」の規模まで小さくなります。 可能であれば、「都道府県, 配送番号」から「都道府県, 市, 配送番号」、というindexにして、都道府県まで絞り込んでから配送番号をIN句検索、ではなく、市まで絞り込んでからIN句検索にすると、もっと早くなります。 トリッキーな例 // prefecture, ordered, shipping_numberの複合ユニークindexがあるとする // それぞれ、都道府県、注文日時、配送番号 SELECT * FROM test WHERE prefecture = ' Tokyo ' AND ordered < {クエリ実行時よりも十分に未来の日時} AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...（略） ); 普通に考えて「未来に注文された注文」というものは存在するはずがありません（少なくともこのテーブルの運用では存在しないとします）。 そんなデータあるわけがないのでわざわざWHERE句に含める意味などないように思えますが、例示したindexを使用するためには、実はこの条件指定は有効です。 ORDER BY 句で日時カラムを使用したい場合など、日時系の入ったindexを使用したい、しかし、検索条件そのものに日時データは不要…というシーンはあると思います。そのような場合に有用な、少しトリッキーな方法です。 取得カラム問題: 取得するカラムが本当に必要かをよく考え、使用するindexをよく考える まず、特に理由のない SELECT * は避けるべきです。これは、ただデータ取得コストを増やすことに繋がります。 処理に必要なカラムが何であるのかをしっかり考えて、最低限のカラムだけを取得することがパフォーマンス面では重要です。 そして、使用するindexを吟味することもとても重要です。クエリに使用可能なindexが複数存在するのはよくあることなので、使用できるindexの中で、indexへのアクセスのみで必要なデータが全て取得できないかを検討します。 また、その処理がアプリケーションの中でとても重要で、indexを追加してでもパフォーマンスを上げたい場合、indexを新しく追加することは十分に価値のあることです。 余談ですが、私の試した中では、indexを追加したことで30秒オーバーのクエリが1.6秒まで短縮できました。それだけの速度差があっても、explainの結果に差はありません。 あえてクエリを分割するという選択肢 次のクエリをご覧下さい。 // idはプライマリキー // shipping_number = 配送番号 // prefecture = 都道府県 // zip_code = 郵便番号 // name = 注文した人の名前 // prefecture, shipping_number, zip_codeの複合ユニークindexがあるとする // 別で、prefecture, shipping_number, nameの複合ユニークindexがあるとする SELECT id, shipping_number, prefecture, zip_code, name FROM test USE INDEX (`test_prefecture_shipping_number_zip_code`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...（略） ); USE INDEX を使用して、使用するindexを固定しています。 この例では、 name カラムについて、テーブルアクセスしてデータを取得するコストが発生します（ id はコストがかかりません。InnoDBでは、暗黙的にセカンダリindexの最後にプライマリキーが勝手に入るため、葉ノードに id は常に含まれます）。 一方で、使用するindexを test_prefecture_shipping_number_name にすると、今度は郵便番号の取得コストがかかります。 実際にやってみて計測して判断する必要がありますが、これは、次のような方法で解決できる場合があります。 // クエリ 1 SELECT id, shipping_number, prefecture, zip_code FROM test USE INDEX (`test_prefecture_shipping_number_zip_code`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...（略） ); // クエリ 2 SELECT id, name FROM test USE INDEX (`test_prefecture_shipping_number_name`) WHERE prefecture = ' Tokyo ' AND shipping_number IN ( ' 0000-0000-0000 ' , ' 0000-0000-0001 ' , ...（略） ); このように、indexのみでデータ取得が完結するようにクエリを分割し、後からアプリケーション側で id を使用してデータをマージする、という方法です。 USE INDEX を使用することで、MySQLのオプティマイザによる自動的なindex選択に任せず、使用するindexを常に固定することができます。 繰り返しになりますが、これは実際に速度計測を行なって検討する必要があります。カラムの型やサイズによっても結果が異なってくるためです。 余談になりますが、私が色々と試した中では10秒かかっていたものが1秒未満まで短縮したというような例もあったため、試してみる価値は十分にあります。 さいごに 「クエリでちゃんとindexを使用できる」からさらに一歩踏み出して「パフォーマンスの出るクエリとindexの組み合わせを検討する」ことで、より速度を出すことできました。 どうしても複雑に見えるindexですが、読み解いていくと意外と単純な側面もあり、基本に立ち返って「辞書の目次」の例で考えてみると理解しやすかったです。 もしこの記事を読んで興味を持たれたなら、ぜひトライしてみてください！