2022-12-14

【レポート】これから始める人のためのデータベース超入門

こんにちは。ニフクラエンジニアミートアップ事務局の鮫島です。

2022年9月7日（水）に第51回ニフクラエンジニアミートアップを開催しました。

今回のテーマは、「これから始める人のためのデータベース超入門」ということで、日本MySQLユーザ会の坂井恵氏を講師にお招きして、データベース（より正確にはリレーショナルデータベース管理システム(RDBMS)）の基礎の基礎（RDBMSが必要である理由から、基本的なしくみ、SQLの考え方など）を初心者向けに解説していただきました。

fujitsufjct.connpass.com

2022-12-12

ニフクラOVM環境でUnixBenchを実行してみた

ベンチマーク・検証ニフクラOVM

こんにちは、CRE部技術支援チームです。

ニフクラではOracle DatabaseライセンスのBYOL(Bring Your Own License)が可能な環境を利用できる、ニフクラOVMを提供しています。
ニフクラOVMは通常のニフクラとは異なる基盤で動作していますが、どれくらいのパフォーマンスの違いがあるのかを確認するためにUnixbenchを実行してみました。

前提条件
検証概要
ニフクラOVMのサーバー仕様について
計測条件
実施方法
計測結果
まとめ
注意事項

前提条件

本ブログは、以下の前提知識がある方を想定しています。

ニフクラの基本的なコントロールパネルの操作、サービスを利用する知識
Linuxサーバーの基本的な操作、知識

検証概要

OVMサーバーとニフクラの通常のサーバータイプ(Type-h2)のサーバーを用意してベンチマークを実施します。
ベンチマークツールはUnixBenchを使用しました。UnixBenchは主にCPU総合性能値を評価するためのベンチマークツールです。

ニフクラOVMのサーバー仕様について

ニフクラOVMのサーバーと通常のサーバー(Type-h2など)では動作基盤が異なります。
以下は「ニフクラOVM（Oracle Database利用環境）サービス仕様書」の該当の説明部分の抜粋です。

2022-11-22

10分で Storage Spaces Direct（記憶域スペースダイレクト：S2D）

S2D Storage Spaces Direct 冗長化 WIndows Server

こんにちは、CRE部技術支援チームです。

「不安定、高負荷、障害、致命的、エラー、赤い文字、赤ランプ ...」
システム運用している方にとっては、絶対に聞きたくない嫌な言葉ですね。

出来れば発生しないに越したことはありませんが、障害は必ず発生するものとして、有事の際でもシステムの可用性、継続性を確保すべく、様々な手段でシステム設計、構築が行われています。

しかし、可用性向上のためには、冗長化のための追加リソースやソフトウェアのライセンスが必要なケースがほとんどであり、どうしてもその分のコストがかかってしまいます。

ニフクラでは、追加コスト不要で提供している自動フェイルオーバー（HA機能）により物理サーバー障害への一定の冗長性を確保できるのはご存じの通りです。

しかし、基本的にはOSレイヤー以上はお客様の責任範囲であり、お客様自身で冗長性を確保するための要件に応じた設計、構築をいただくことになります。

ロードバランサーやクラスタリングソフトウェアの利用は、よく採用される冗長化の手法ですが、必要なハードウェア、ソフトウェアリソースが増え、共有ストレージを組み合わせての全体設計は複雑になりがちです。

そこで今回は、よりコストをかけず、なるべく少ないリソース／短時間でサーバーとストレージ含めた冗長構成を可能とする、Windowsサーバーの「 Storage Spaces Direct 」(S2D)機能について検証してみます。

Storage Spaces Direct (S2D)とは

Storage Spaces Direct （以降S2D）とは、「記憶域スペースダイレクト」とも呼ばれている技術で、サーバーのローカルディスク領域を使用してクラスター共有ボリューム（CSV）や、スケールアウトファイルサーバー（SOFS）を構成する機能です。外部に共有ストレージが不要であり、複数のWindowsサーバーのみで構築可能です。

S2Dの仕様および構築要件については、記憶域スペースダイレクトのハードウェア要件 | Microsoft Learn を参照してください。（外部サイトのため、リンク切れの際はご容赦ください。）

構成イメージ

本検証では、以下構成図の通り環境を実装しています。

2022-11-09

Redisのクラスター構成の性能検証を実施してみた

データベース Redis ベンチマーク負荷分散

こんにちは、CRE部技術支援チームです。

皆さんは、データベース（以下DB）を利用する際、何らかの理由で負荷が高まりサーバーのレスポンスが遅くなった経験がありませんか？

このような時、キャッシュサーバーを有効に活用することで、DBサーバーの負荷低減やリクエストへのレスポンス時間の改善ができるかもしれません。

今回はキャッシュサーバーとして利用できる代表的なオープンソースのインメモリーDBであるRedisのクラスター構成を試してみます。

Redisはデータを全てメモリー内に持つため、非常に高速なパフォーマンスを実現できます。データベースのキャッシュの他、中間処理を行うためのデータストア、セッション情報などの一時的なデータの保存場所としての活用が可能です。
本記事ではサーバータイプによってRedisの処理性能がどのように変わるのか、Redis1台のみの構成とRedis clusterの構成をそれぞれ準備してベンチマークを実施しました。