Infra on Yossy's Notes

DBインスタンスを最大6台から2台に削減した話

Sun, 12 May 2024 12:00:00 +0900

自己紹介

私は、現在とあるWeb系のベンチャーでWebアプリケーションエンジニアとして開発業務に従事しています。

今回の記事では以前勤務していた株式会社ZUUでの開発に関して投稿したいと思います。

今回は肥大化したDBにインデックスを付与することで、DBインスタンス数を最大6台から2台までに改善することができたので説明していきたいと思います。

本記事は個人の見解です。

サービスについて

株式会社ZUUでは金融に関する記事を掲載する様々なメディアを運営しています。

ZUU Onlineやfuelle、MoneyTimes、dメニューマネー、その他にも多数メディアを運営しております。

一部メディアでは、ユーザー機能を提供しており、その中にお気に入りの記事をクリップする機能などがあります。

概要

弊社の顔でもZUU onlineは、ローンチして約○年経ち、記事数やユーザー数ともに大きく成長しました。ただその一方でパフォーマンスの劣化などが問題となりユーザビリティを下げてしまうことに課題がありました。

前提

使用しているDBMSはPostgreSQL12です。

今回改善したクエリを簡単な図で説明します。

運用しているメディアでは、ユーザーが記事をクリップする機能が提供されています。

その一部であるユーザーごとにクリップを取得する機能がボトルネックとなっていました。

（以下のテーブルは例です。実際のテーブルとは異なります。）

erDiagram
 articles {
 id integer pk
 title text
 content text
 }
 article_clips{
 article_id integer fk
 user_id integer fk
 }
 users{
 id integer pk
 name text
 }
 articles ||--o{ article_clips : article_id
 users ||--o{ article_clips : user_id

それぞれおおよそ以下のレコード数を持っています。

テーブル名	レコード数
articles	120,000
article_clips	2,800,000
users	200,000

スロークエリの分析

スロークエリが判明したので、実行計画をもとに分析していきます。

Redisの負荷を1/3改善した話

Sat, 16 Dec 2023 12:00:00 +0900

はじめに

現在とある金融系Webメディアを運営する会社で、主にバックエンドの開発を担当しており、フロントエンド、インフラに関する業務も担当しています。

今回は、先輩エンジニアがデータ圧縮アルゴリズムを変更することでRedisの負荷を1/3に削減することに成功した実例をもとに記述して行きます。

先輩エンジニア(通称 ichigozero)は、vimmer, hacker, rustが得意なエンジニアです。（共通の趣味（おうちKubernetes）について語り合うのが日課です。笑）

サービスの概要

金融に関する記事を掲載するWebメディアを運用しています。

背景

現在運用しているメディアでは約100万記事掲載しており、直近一年で約50万記事と急激に増加し、Redisのパフォーマンスが劣化する課題がありました。

RedisのCPU使用率が高負荷状態になると、インスタンスを増やすことで一時的な対応を行っていました。

そこで根本的なアプローチをし、改善を行うとなったのが背景です。

*別アプローチも行っており、大幅な改善が見られました。別記事にて紹介する予定です。

前提

データ取得のフロー

サーバーでは、Redis->PostgreSQLという順番で問い合わせを行っています。

sequenceDiagram
 participant Client
 participant Server
 participant Redis
 participant PostgreSQL

 Client->Server: リクエスト

 Server->Redis: Redisからデータを取得
 Redis->Server: データが存在する場合、データを返す

 alt Redisからデータが存在しない場合
 Server->PostgreSQL: PostgreSQLからデータを取得
 Server->Redis: データを保存
 end

 Server->Client: レスポンス

解決策

データ圧縮アルゴリズムのGob形式から、パフォーマンスの高いアルゴリズムであるMgspack形式とSnappy形式を採用することで、大幅な改善に成功しました。

採用理由

データ圧縮のベンチマークについては、GobとMgspack + Snappyは同等のパフォーマンスです。

しかしバイトサイズを比較するとMgspack + SnappyがGobと比べ、半分のサイズに圧縮することができています。

結果、Redisのベンチマークを比べるとns/op(1回の操作にかかる平均時間)が約11%、B/op(1回の操作で消費する平均メモリ量)が約3%、allocs/op(1回の操作で生成される平均割り当て数)が約80%と大幅に改善したので採用しました。

ベンチマーク

データ圧縮のベンチマーク

BenchmarkJSONMarshal-12 	 45304	 25614 ns/op	 17984 B/op	 35 allocs/op
BenchmarkJSONUnmarshal-12 	 14763	 81072 ns/op	 31334 B/op	 74 allocs/op
BenchmarkGobMarshal-12 	 120536	 10011 ns/op	 29876 B/op	 51 allocs/op
BenchmarkGobUnmarshal-12 	 56109	 21446 ns/op	 36464 B/op	 243 allocs/op
BenchmarkMsgpackMarshal-12 	 373802	 2888 ns/op	 28005 B/op	 5 allocs/op
BenchmarkMsgpackUnmarshal-12 	 369746	 3261 ns/op	 15286 B/op	 34 allocs/op
BenchmarkMsgpackSnappyMarshal-12 	 55236	 21330 ns/op	 44386 B/op	 5 allocs/op
BenchmarkMsgpackSnappyUnmarshal-12 	 140824	 8507 ns/op	 28951 B/op	 35 allocs/op

Redisベンチマーク

これだけは知っておきたいDNS

Sun, 30 Jul 2023 12:00:00 +0900

はじめに

DNSについて、最低限知っておきたいポイントを整理しました。誰かのお役に立てれば幸いです。

登場人物

DNSを動かすために必要なこと

自分のドメイン名をインターネットでつけるようにする　- 権威サーバーを動かすことで自分のドメイン名をインターネットで使えるようにする
インターネットで使われているドメイン名を自分が使えるようにする
- フルリゾルバー、スタブリゾルバー、特にフルリゾルバーを動かすことでインターネットで使われているドメインを自分で使えるようにする
DNSを動かし続け、可用性を高める
- 問題なく動作していることを確認すること、外部攻撃に備え動かし続ける必要がある

DNS設計

ユースケース

運用しているサービスやサーバーが少ない場合サブドメインを作成せず、階層構造を持たないフラットな管理をする。
部門別のシステムをサブドメインを作成し、システム部門が全体の管理する場合 1つのゾーンで運用する
他部門が独自サブドメインを使ってサービスサイトを運用し、そのサブドメインもその部門が管理する場合サブドメインを作成し、ゾーンの管理をその部門委任する

権威サーバーの可用性

プライマリサーバーとセカンダリサーバーの設置

役割プライマリサーバーがセカンダリサーバーからのゾーン転送の要求を受け、要求されたゾーンデータを送る

考慮すること

プライマリサーバーをセカンダリサーバーへのゾーン転送のコピー元としてだけ使う。

利用者からの問い合わせは受け付けないように構成するプライマリサーバーのIPアドレスをプライベートにすることで、サイバー攻撃のリスクを減らすことができる

ゾーン転送の仕組み

AXFR 全てのゾーン情報を転送する
IXFR 前回のゾーン転送情報をジャーナルファイルに記録しておき、ゾーン転送時にはジャーナルファイルを参照して差分情報のみを転送する

権威サーバーが応答する情報

リソースレコードの表記フォーマット
- TTLとクラスは省略できる
- 同じドメイン名に複数のリソースレコードを設定する場合、二行目以降はドメイン名を省略できる

<name> <TTL> <class> <type> <data>

フルリゾルバー

役割

利用者の機器で動作するスタブリゾルバーから名前解決要求を受け付け、名前解決を行い結果を返す

考慮すること

ネット上に設置された権威サーバー群に問い合わせを送るため、一般的にグローバルIPを割り当てる
利用者のネットワークからアクセスしやすい場所に設置することが望ましい

代表的に攻撃手法

DNSリフレクター攻撃

DNSを利用したDoS攻撃の一つ

送信元IPアドレスを偽った問い合わせをフルリゾルバーや権威サーバーに送ることでそれらのサーバーが応答を攻撃対象に送りサービス不能の状態に陥らせる

対策

RRL(Response Rate Limiting)の導入

[検証]DockerのMulti-stage builds

Sat, 18 Mar 2023 12:00:00 +0900

背景

DockerImageのMulti-stage buildsをするとサイズがどのくらい落ちるか気になったので、検証しました。

対象としている人

Docker学習中の人
Docker Imageを実装している人

実験結果

一目瞭然ですね。まさかの約370MBの違いもありました。

Goのベースイメージを採用したDockerImage golang:1.19をベースイメージとして使っています。

Multi-stage buildsを採用したDockerImage scratchをベースイメージとして使っています。

それぞれのDockerImage

Goのベースイメージを採用したDockerImage

FROM golang:1.19
WORKDIR /usr/src/app
COPY . ./
RUN go mod download && go mod verify
EXPOSE 8000
CMD ["go", "run", "./cmd/main.go"]

Multi-stage buildsを採用したDockerImage

# syntax=docker/dockerfile:1
FROM golang:1.19 as builder
WORKDIR /usr/src/app
COPY ./backend/go.mod ./backend/go.sum ./
RUN go mod download && go mod verify
COPY ./backend .
RUN CGO_ENABLED=0 go build -o binary ./cmd/main.go
FROM scratch
WORKDIR /usr/src/app
# scratch doesn't have timezone.
COPY --from=builder /usr/share/zoneinfo/Asia/Tokyo /usr/share/zoneinfo/Asia/Tokyo
COPY --from=builder /usr/src/app/binary /usr/src/app/binary
COPY ./backend/configs.yaml .
EXPOSE 8080
CMD ["./binary"]

Kubernetesリソースメモ

Wed, 18 Jan 2023 12:00:00 +0900

背景

以外と忘れがちなリソースについて、まとめました。

対象としている人

Kubernetesを学習途中の人、またこれからKubernetesを学習しようとしている人

リソース

Pod

PodはKubernetesにデプロイ出来る最小単位

コンテナやボリュームの集まり

Deployment

新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用することができる

ReplicaSet

どんな時でも指定された数のPodのレプリカが稼働することを保証する
spec.templateをハッシュ値で管理しているため、ロールアップ・ダウンによる変更に即座に対応できる。

Ingress

IngressはHTTPやHTTPSの外部アクセスを制御するオブジェクト
Load Balancerの役割をしている。

Service

動的にIPAddressが変更されるPodへの接続を解決してくれる抽象的なオブジェクト
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法

役割

Pod,Nodeの存在を抽象化し、Podとの通信に単一のエンドポイントを提供する

Volumeについて

コンテナのデータは一時的なもので、Pod/コンテナが削除されるか、コンテナがクラッシュした場合コンテナのデータは消えてしまう。そこでVolumeを使う

メリット
- Volumeはデータの永続化をしてくれる。永続化したいデータは指定したVolumeに保存することで削除やクラッシュした際でもデータが残る。
- また、Volumeは別の目的でも使用される。それはPod内でのコンテナ間のデータ共有だ。
- Pod内のコンテナはVolumeを通してデータを共有することが出来る。

種類

emptyDir
- Podがノードに割り当てられたときに最初に作成され、そのPodがそのノードで実行されている限り存在する
- 名前が示すようにemptyDirボリュームは最初は空
- Podが削除された際に対象のVolumeのデータも削除される。よってPod内のコンテナ間のデータ共有のみで使用
hostPath
- データが永続化されている(Podが削除されてもデータは消されない)
- Kubernetesが実行されているサーバーにデータが置いてある

ConfigMap

機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクト

Secret

Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクト
PodがSecretを使う方法は3種類がある。
- ボリューム内のファイルとして、Podの単一または複数のコンテナにマウントする
- コンテナの環境変数として利用する
- Podを生成するためにkubeletがイメージをpullするときに使用する

HorizontalPodAutoscaler

Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせる
podの負荷に応じて自動的にpodの数を増減させる

PodDisruptionBudget

Podの最小の有効状態や最大の無効状態の数を指定する
Podの管理対象はLabelSelectorで指定する
フィールドのメモ
- spec.maxUnavailable : Eviction実行時にPodを無効状態にしていい最大数を指定する。絶対値か百分率で指定する。
- spec.minAvailable : Eviction実行時にPodを有効状態にしておく最小数を指定する。絶対値か百分率で指定する。
- spec.selector : このBudgetを適用する対象のPodを選択するLabelSelectorを指定

CronJob

CronJobはJobをcronのように定期実行するためのKubernetesのWorkloadリソース
- 時間ベースのスケジュールでJobを作成するKubernetesオブジェクト
concurrencyPolicy Jobの並行実行についてのポリシーを指定できる
- Allow
  - 並行なJobの実行を許可するポリシー
- Forbid
  - 前回のJobがまだ実行中で完了してない場合、スケジュールされたJobはスキップされる
- Replace
  - 前回のJobがまだ実行中で完了してない場合、前回のJobをキャンセルし新しくスケジュールされるJobに置き換える

Job

一つ以上のPodを作成することである特定数のPodが正常終了するまでリトライしながら処理を実行するKubernetesのWorkloadリソース
- Podの実行が失敗したり削除された場合はJobは新たにPodを起動する
- 平行に複数のPodを起動することも可能
- 指定された数が正常に終了した際にJobが完了
- Jobを削除するとそのJobによって作成されたPodも削除される

Namespace

同一の物理クラスター上で複数の仮想クラスターの動作をサポートする
- kubectl api-resources --namespaced=trueでどのリソースが適応なのか確認できる

おまけ

Manifestについて簡単なメモです。

Dockerのdepends onについて

Tue, 17 Jan 2023 12:00:00 +0900

背景

Dockerのdepends_onについて、簡単に学んだことをまとめました。

対象としている人

Dockerについて、一通り学習したことがある人

depends_on

サービス間の依存関係を指定できる

services:
 service_a:
 image: busybox
 service_b:
 image: busybox
 # `service_b` を `service_a` に依存させる
 depends_on:
 - service_a

service_b を service_a に依存させることができます

docker-compose up: service_a → service_b の順に起動する
docker-compose run: （ docker-compose up と同じ）
docker-compose stop: service_b → service_a の順に停止する

指定パターン

Short syntax （リスト）
- 依存先のサービス名を単純に記述するだけ

depends_on:
 - service_a

Long syntax （オブジェクト）
- 依存関係にあるサービスをオブジェクト形式で記述するもの
- この方法では依存先に加えて「条件」を指定することができます

depends_on:
 service_a:
 condition: service_started

条件の指定には condition を使用 condition にデフォルト値は無いため、 long syntax を選ぶ場合は必ず指定する必要があり