開発5センター
こんにちは、開発5センターの Zhu です。現在は LINE NEWS の SRE チームに所属しています。 この記事は、2023年3月末にサービス提供を終了したライブ配信サービス「LINE LIVE」において、今まで行ってきた施策の紹介や大規模サービスならではのクロージングに関わる話を連載するシリーズの2本目の記事です。今回の記事では、データベース上で Replication Delay によって起きていた問題と解決までの経緯やDB構成について、図を交えて紹介します。 背景 LINE LIVE では、大規模のアクセスに耐えるために DB(MySQL) へのアクセスは Read/Write で分離しています。つまり書き込みは MySQL のクラスター Source へ、読み込みは Replica から行う実装でした。よく使われている手法ですが、イメージの概要は下図の通りです。 DB に書き込み処理をしてコミットした際の大まかなフローは下記です。 バイナリログ (binlog) に書き出されます。次に、バイナリログダンプスレッドがバイナリログの
Fellow of the Business Platform Development
LINE 株式会社 B2B Platform 開発担当フェローの Matsuno です。 LINE の Business Platform ではメインのデータベースとして MySQL を利用しています。MySQL は非常に高速に動く OSS の RDBMS なので、とても便利に利用させていただいております。 MySQL はとても高速なのですが、うっかり index を使わないクエリを発行した場合に実行がとても遅くなってしまうことがあります。LINE の Business Platform はとても多くのお客様が利用されるので、B2B としては異例なほどトラフィックが多く、少し遅いクエリが発生した結果としてサイト全体がダウンしてしまう可能性もあります。 そこで、防御策として我々は ExplainPolice とよんでいる手法を長年採用しているので、それを今回はご紹介しようと思います。 ExplainPolice とは 複雑なクエリを実装する際には、クエリの実行計画をきちんと考えて実装することが大事ですね。 MySQL では EXPLAIN 文を利用することで、クエリの実行計画を調べること
自己紹介 東京大学情報理工学系研究科 修士1年の新道明吉と申します。 技術職の就業型インターンシップに参加し、LINEスキマニという新規サービスのサーバーサイド開発を担当させていただきました。以下ではインターン中に取り組んだ業務（主に2つ）、そしてインターンの感想などを書いていきます。 LINEスキマニ LINEスキマニとは、ユーザーの「ちょっと空いている時間に働きたい」というニーズに応え、「急に予定がなくなった」「数時間だけ空いている」といったスキマ時間に、自分の経験・スキルに合ったアルバイトを探して応募すると、選考なしでその店舗で働くことができます。従来のアルバイトでは面接して採用を待つ過程がありますが、LINEスキマニではそういった選考の過程がないため、本当に短いスキマ時間でも、求人があれば働いてお金を稼ぐことができる魅力的なサービスです。 スキマニサービスは主にKotlin + Spring Bootを用いて開発されているのですが、僕は全く触ったことがなかったため、初めの期間はKotlinとSpring Bootの勉強も兼ね
LINEポイントの開発をしています。主にサーバサイド。
この記事は、LINE Engineering Blog 「夏休みの自由研究 -Summer Homework-」 の14日目の記事です。 開発3センターでサーバサイドの開発を行っている大原（@kory1202）です。私の部署ではLINEポイントの開発を行っています。 先日、あるテーブルからデータを抽出するコードを書いていたら先輩に「こういうインデックスが必要だよね。」と言われてインデックスについて知識が浅いことに気づかされました。そこで今回はインデックスについて MySQL Workbench の VISUAL EXPLAIN を使いながら勉強した内容を記事にしました。 VISUAL EXPLAIN は SQL の EXPLAIN を図で表示してくれるので、直感的にどの部分が悪いのか、インデックスを導入した時にどの処理が改善されるのかが直感的に分かるので非常にオススメです。 今回は MySQL 5.6 の InnoDB について話します。実験に使った OS は macOS High Sierra 10.13.4 です。以下目次。 インデックスの基礎 インデックスの構造 インデックス
