これはなに この記事は米シリコンバレーでデータベースコンサルや教育事業を展開するKloudDB社がポストした『Understanding How ONLINE DDL (INPLACE) works in MySQL』の翻訳記事です。 この記事ではDDL（スキーマ変更クエリ）の内部処理について詳細に解説しています。DDLはシンプルに利用できるものの、一歩踏み込むと複雑怪奇で理解の難易度は高いものでした。この記事はそこに焦点を当てたものになります。 翻訳するにあたり、技術的な正確性を担保しつつ、日本語表現として自然になるよう努めました。もし記事の中で技術的な観点で不正確な箇所があれば訳者の責任ですので、コメント欄などでご指摘いただけると幸いです。 また、翻訳について許可を下さったSrinivasa R Inaganti氏（同社CEO）に感謝します。 以下、訳者による前書き的なものを挟んで、翻

これはなに ども、LT開発部のもりたです。 今回はMySQLのスキーマ変更（DDL）について調べました。 DDLってなんとなく使うことは可能なんですが、データ量が増えていくにつれて障害の要因になったりもしますよね。もりたも障害が起きてDDLを調べたクチなんですが、調べれば調べるほどDDLに関する断片知識が絡まり合い、整理をつけるのが大変でした。今回はその断片を撚り合わせ、綺麗に縫合することで、この１記事だけで大体全てがわかるようにしました。もしDDLでお困りの方がいらっしゃいましたら、この記事（と、そこから辿れる諸記事）を足がかりに基礎と応用を身につけていただければと思います。 また、有識者の方々は是非まさかりを構えながら読んでください。技術的な間違いや現場的にはこうだよという事項がありましたら、コメント欄に記載いただけると幸いです。 構成 構成 まず構成ですが、以下の通り進めます。 前提

TL;DR アーキテクチャカンファレンス 2024 に参加した トレードオフ分析では、評価軸の重み付けや市場の変化に応じた継続的見直しが重要 組織とアーキテクチャは相互に影響を与える アーキテクチャはあくまでビジネス目標達成の手段であることに留意するべき 進化的アーキテクチャ実現のために、シンプルさと柔軟性を重視し、偶有的複雑性を最小化するべき はじめに こんにちは、直近はシステムのリプレースに着手している内藤です。 リプレースや大規模な設計変更を進めている方にとって、アーキテクチャ設計の悩みは尽きないですよね... 先日参加した「アーキテクチャカンファレンス 2024」では、こうした課題へのヒントとなるテーマが数多く取り上げられていました。本記事では、その中でも特に印象的だった「トレードオフ分析」「組織とアーキテクチャの相互作用」「進化的アーキテクチャ」に焦点を当て、私が得た知見を共有で

この記事は「レバテック開発部 Advent Calendar 2024」の 22 日目の記事です！ 昨日の記事は、うちさんの「CIのボトルネックを特定してJestの実行時間をチョット速くした話」でした。 はじめに レバテック開発部でオウンドメディアおよびデザインシステムの開発を担当している本名です。 12月12日にレバテックLABのメンテナンスがありました。 レバテックLABは、AWS EC2上でWordPressを稼働させてAurora2系をDBとして利用してきましたが、運用まわりで以下の対応に課題が出てきていました。 手動でのスケール・復旧作業 冗長構成になっておらず、メモリ逼迫が常態化していました 外形監視でアラートが発砲され、気づいたらサービスが落ちていたなんてことがあったり… サービスの特性上、不測のタイミングで記事がバズってPV数が跳ねてこの状態になったします ライブラリなどシ

この記事は「レバテック開発部 Advent Calendar 2024」の 1 日目の記事です！ TL;DR TypeScript ユーザーが Haskell を写経しながら学んでいった記録です 題材は「JSON Parsing from Scratch in Haskell」で、この記事自体はこれのコードリーディングのメモみたいなものになります うまく言えないのですが、型に対するメンタルモデルが変わった感じがしました 初日から長ったらしい記事を書いてしまったので、早めにまとめが来るような書き方をしました。そこだけでも読んでいただければ🙏 はじめに レバテック開発部でバックエンドエンジニアをしている瀬尾です！ テックブログ運営も担当しており、今年はアドベントカレンダーを企画しました〜 その 1 日目として今回の記事を書いています。 バックエンドといえば、関数型スタイルで書くと型システムを

これはなに どうも、レバテック開発部のもりたです。 この記事は「レバテック開発部 Advent Calendar 2024」の 2 日目の記事です！ 昨日の記事は、seoink さんの「TS ユーザーが初見の Haskell を写経して型への認識をすこし改めた記録」でした。学びのワクワク感が詰まっててよかったぜ...！！ アドベントカレンダー2日目の本記事では、年末に（もりたが）読みたいな〜と思っている要件定義関連の書籍を23冊紹介します。要件定義の書籍ってイマイチ抽象的だったり、自分の知りたい情報とずれている気がして読むのが難しいですよね。もりたはず〜〜〜〜っとそうだったんですが、最近読み方が分かってきました。それが嬉しいので、要件定義関連書籍の読み方に悩める諸氏に向けて、要件定義の主要な論点を明示した上で書籍を紹介していきます。 扱う領域と扱わない領域 では具体的に、今回ご紹介する/紹

これはなに ども、レバテック開発部のもりたです。 今回はトランザクション分離レベルについてまとめました。トランザクション分離レベルって基本情報技術者試験とかで学ぶものの、座学だけだとあんまりピンとこずに忘れちゃいますよね。もりたも長らく曖昧な状態で生きていたのですが、よい理解の仕方があったので今回はその解説をします。 トランザクション分離レベルを構成するふたつの変数 トランザクション分離レベルとは まず初めに、概要を掴むところからいきましょう。 トランザクション分離レベルとは、あるトランザクションのデータベースに加えた変更が、他のトランザクションにどの程度影響を与えるか？　というもの（分離性、独立性）を一定基準でレベルに分けてまとめたものです。 どの程度影響を受けるか？　については三つの影響が定義され、その影響度合いに応じて分離レベルが４つ存在します。これは大体こんな図で解説されます。 よ

読書感想文「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」 はじめに こんにちは、レバテックCTO室でテックリードを担当しているかわうそです。 今回は、夏といえば夏休みの宿題、夏休みの宿題といえば読書感想文ということで読書感想文を書いてみました。 読書感想文の対象読書として選んだのは、”ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた”になります。 特に選んだ理由とかはないんですが、 読書感想文を書いてみようと思ったタイミングと読もうと思ったタイミングがたまたま重なったのが理由です笑 感想 読んでみて最初に思ったことは「うわーそれあるあるだわぁ」がたくさんあったことですw ソフトウェア開発をしていると幾度も失敗をしてしまうことはあると思いますが、こういった失敗を他のエンジニアたちもしているんだなと思うと

はじめに はじめまして！レバテック開発部でレバテックプラットフォーム開発チームに所属している塚原です。 直近に認証・認可周りの改修を予定しているため、チーム内で認証・認可の基礎からOAuth・OpenID Connectの仕組みを学ぶ勉強会を実施しました。今回はそこで学んだことのうち、認証・認可の基礎とOAuthの仕組みをまとめます。また、WebフレームワークとしてHono、JavaScriptランタイムとしてBunを使って、OAuthクライアントを実装してみます。 対象読者 認証と認可の違いってなんだっけ...?という人 Basic認証やDigest認証てなんだっけ...?という人 OAuthはライブラリ使って実装してるから仕組みよくわかっていない...という人 OAuthのクライアントの実装って何をすればいいんだっけ...?という人 認証・認可の基礎 2024/7/18 追記 こちらで

初めに レバテック開発部の今井です。 ソフトウェア開発において、データの状態管理は非常に重要です。注文の状態、ユーザーの認証状態、プロジェクトの進行状態など、多岐にわたる状況で、適切な状態管理が求められます。しかし、ビジネス要件の変化や新機能の追加に伴い、状態管理が複雑化し、保守が難しくなることがあります。 この記事では、データの状態管理を簡単にするためにMECEを初めとした方法で分析を提案します。これによって、柔軟で効率的なシステム設計が可能になることを目指します。 TL;DR MECEの原則を使ってenum型ステータスを分解する方法を解説する MECEによる分解から一次情報と二次情報という区分を提案し、分析の高度化を目指す 一次情報と二次情報の区分とシステム間のデータ連係の関係性について考察する 対象読者 システムの保守性・拡張性に興味関心のあるエンジニア enumをMECEに分解する

はじめに 業務委託の丹羽です。 レバテックフリーランス経由で、レバテック開発部のSREチームに業務委託で参画させていただいています。 業務委託の私でも、我が物顔でレバテック開発部のテックブログに寄稿して構わないとのことなので、今回は掲題の件について、振り返りながら記事にさせていただきます。 ざっくりこんな人 AWSの基盤となるクラウド部分と、EC2内部でOS・ミドルウェアをメインに、各パラメータを修正したり、それらをAnsibleに書き起こしてCodeCommitで管理しているくらいのIaC経験があるインフラの人でした。 そこからスキルアップと挑戦をしたいという思いで、フリーランスに転向してSREやDevOpsに興味を持ち始めた人です。 SLI/SLO...？ CICD...？ 何それ、美味しそう！ 話したいこと フリーランスってどんな仕事してるの？ レバテックフリーランスに興味のある方は

はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画

レバテック開発部の前原です。以前はプラットフォームチームとしてマイクロサービスの開発を行っていましたが、開発部の新たな試みにより、事業の特定の問題を解消するチームとして社内の営業支援システムの改修を行っています。 はじめに レバテックの社内の営業支援システムでは、数多くのステークホルダーからの要望をもとに開発が行われます。ステークホルダーからは「このテーブルにカラムを追加してください」といった具体的な要望が多く寄せられます。開発部ではこれらの要望に対して検討を重ね、要件の調整を行いますが、多くの場合、そのままカラムを追加することが多いです。 カラムの追加によって要望が実現されるかは考慮されますが、データモデリングを通して「モデルにどのような概念を含めるか」の検討は不十分でした。 その結果、本来必要な概念がデータモデルに反映されず、運用で問題をカバーすることになりました。これにより問題の解決

はじめに こんにちにんにん、 art です。 僕が所属するレバテック開発部では、最近デザインシステム『VoLT』が誕生しました。 レバテックでは複数のプロジェクトが運用されており、フロントエンドの技術スタックは Vue.js × Nuxt React x Next.js の２つが採用されています。 ですので、両方の技術スタックに対応したデザインシステムを作る必要があるわけですね。 あら大変。_(:3 」∠ )_ というわけでこの記事では、『VoLT』のUIコンポーネントライブラリを制作するにあたり、肝となったデザインシステムのマルチフレームワーク対応についてお話しします。 🔗そもそも『VoLT』とはなんぞや？構築の背景は？と気になった方は、こちらをご覧ください！ 想定読者 デザインシステムに興味のある方 これからデザインシステム関連の業務に携わる方 すでにデザインシステム関連の業務に携わ

はじめに はじめまして。レバテック開発部ITSプロダクト開発グループ所属の池永です。 私は現在スクラムマスターとしてチームに参画しており、日々チームが強く、楽しくなれるように試行錯誤しております。 かれこれ一年半ほどスクラムマスターを経験させていただいてきましたが、色んな壁にぶつかってきました。 特にスクラムにおける「ふりかえり（レトロスペクティブ）」において生じた壁について色んなエンジニアと話しているうちに、あるあるなんだなぁ〜と感じたため、この記事を書いております。 この記事では自身のぶつかってきた壁と、そこに対してどのようなアプローチを取ったか、そしてどうなったかを少しだけ共有しようと思います。 何かしらの参考になったら幸いです。 話すこと スクラムにおけるふりかえりのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと 色んなふりかえり手法に

これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

このように、REST の設計原則に従って API を構築することで、ほとんどの API 設計は直感的に、かつ問題なく行うことができます。 デザインパターンの紹介 ここからが本題です。大抵の場合、上の例で示したような API 設計で十分です。 ただ、複雑な要件では、上のような典型的な API 設計のみでは良いAPIを設計するための4つの特性を満たせないことがあり、そのような場合のためにデザインパターンが有効です。 カスタムメソッド 概要 カスタムメソッドは、標準的な CRUD 操作（作成、読み取り、更新、削除）では対応できない特定の操作が必要になる場合に便利です。例えば、メールの送信や即時の文書翻訳など、通常の create や update メソッドでは処理が難しい操作がこれに該当します。 参考までに、以下に Google が出しているカスタムメソッドの記事を示します。 実装例 以下は、カ

伝えたいこと 論理的思考だけでは立ち行かない厄介な問題への武器として、システム思考という選択肢も持っておくと分析の幅が広がるかも 要約 レガシーシステム、どうする？というありふれた厄介な問題 どうすべきかの仮説はあるけど分析が甘そう システム思考で解像度UP、新たな仮説を立てられた 社内のレガシーなシステムを今後どうしていくか？ システムの詳細は省きますが、10年くらい前からシステムを持っている多くの企業が、この問題を抱えていると思います。 この問題をどうにかするためにマイクロサービスが流行し、成功したり失敗したり、、今も闘っている企業は多いでしょう。 弊社はマイクロサービス化に失敗した側で、今も闘い続けているのです。 どうアプローチすれば良いかわからない レガシーシステムは総じて歴史が深く、事業を支えてきた重要なシステムです。 故に規模は大きくなり、関係者も多くなり、変更容易性は下がって

TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので

はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR