こんにちは。入社１年目のS.K.です。
今回は、６月の勉強会についての記事になります。
テーマは、「Docker」と「Redis」についてです。

まずは、Dockerについて。エンジニアの方々は耳にしたことや、実際に利用しているという人も多いのではないでしょうか。
Docker, Inc.によれば、「開発者がコンテナー アプリケーションを構築、共有、実行できるように設計されたプラットフォーム」とのことですが、今回はその「コンテナ」に着目してDockerを見ていきたいと思います。
この発表を行ったのは、昨年８月に入社したC.S.さんです。発表ありがとうございました。

Dockerとそれ以前の仮想環境

Dockerは主に仮想環境の構築・共有などに利用されています。
まず初めに、類似の目的で利用されるVMとCloud Serverとの比較を行っていきたいと思います。

2000年代には、VMwareやKVMなどの技術を利用した仮想環境（VM）を構築することで、開発環境とリリース環境の隔離が実現できていました。
VMでは、高いリソースの隔離性がありましたが、仮想化のためにHypervisorなどを挟む必要があります。そのため、余計な負荷や処理の時間が必要になり、パフォーマンスが低下するという問題を抱えています。

2010年ごろには、OpenStackコミュニティが設立されリソースのオンデマンド配分を実現しました。クラウドサーバーの登場です。
クラウドサーバーはリソースごとに料金体系を実現し、迅速に配置を調整することができます。一方で、同一の環境を共有するという機能は備えていません。このため、環境差異の問題が生じる可能性が残っています。

Dockerが台頭したのは2013から2014年にかけてです。
Dockerの最大の特徴は「コンテナ」と呼ばれる、アプリケーションとその実行環境を1つにまとめあげる技術が実装されていることです。コンテナはコンテナエンジン（図中のDocker Engine）を挟むことによって、ホストのオペレーティングシステムのカーネルを共有することができます。
これによって、OSなどを環境ごとで設定する必要がなく、Dockerが導入された環境であれば他の環境にそのまま共有・実行することができます。この特徴のおかげで、Dockerによる仮想環境は高いリソースの利用効率とメンテナンス性を備えています。

Dockerのコンテナ技術の概要

Dockerの本質はプロセスリソースを分離する技術にあります。この点について、簡単に触れておきたいと思います。
DockerはLinuxの技術からなるRuntimeとImage(roofs)の部分に分けることができます。

NamespaceはLinuxのリソースを分離する技術です。
コンテナごとに Namespace を持つことで、ホストや他のコンテナとの分離を実現しています。

CgroupsはLinuxカーネルのハードウェアなどのリソース制限を行うための機能です。
これによりシステム管理者が、システムリソースの割り当てや管理などの細かいコントロールが可能となります。

Docker Imageはファイルシステムの分離を担っています。
Dockerのコンテナを動作させるのに使うテンプレートファイルを指し、これを実行することによって実行環境のコンテナが生成され、アプリケーションが実行されます。
大まかに3つの部分で構成され、以下の図のような形になっています。

まとめると、一つのマシンの中でNamespaceとCgroupsによって実行に利用するソフト・ハードのリソースを隔離し、Docker Imageに記述された命令に基づいてプロセスを実行しています。
よって、コンテナとはリソースの隔離行い、その中で実行している特別なプロセスであるということがわかります。

結論

Dockerはコンテナ技術によって環境の一貫性を保つことができ、開発において他の仮想環境を利用した技術よりも、パフォーマンスやメンテナンス性に優れていることがわかりました。
一方で、コンテナの仕組み自体は複雑なものではなく、NamespaceやCgroupsなどによるリソースの隔離が行われた、特別なプロセスであることもわかりました。

Redis（REmote DIctionary Server）は、メモリ上で動作するインメモリデータベースの一種です。
データベースの管理システムとしては、NoSQLに分類されるものになります。
高いパフォーマンスと多様な機能によって、最近人気のデータベースのようです。
発表者は、昨年9月入社したL.S.さんです。発表ありがとうございました。

Redisの特徴

Redisは速度と機能性を両立したNoSQLで、以下のような特徴を持っています。

• ①メモリ（RAM）上にデータを保存。ストレージ（SSDやHDD）よりも非常に高速なデータのやり取りが可能。
• ②RAM上にデータを取り扱うが、ストレージへの保存（永続化）が可能。
• ③豊富なデータ構造、データ型。
• ④複数のコマンドの原子的な実行が可能。

ここまで読むと、Redisはデータベースとして極めて理想的に思えますが、重大な欠点もあります。
それは、肝心のRAMが容量単位で見たときに、SSDと比較して非常に高価であることです。

通販サイトなどで調べると、1TBのSSDはおよそ10,000~13,000円程度の価格で購入することができます。一方で、ミドルレンジ以上のゲーミングPCなどでよく見るRAMも同等の価格で購入できますが、容量は32GBしかありません。iPhone 14までは最小ストレージが64GBだったので、これの半分程度しか保存できないと考えるとかなり少なく感じます。
同じ32GBのRAMの中でも、転送速度がさらに速いものになれば、15,000円を超えてくるものも存在します。

以上のことから、Redisは高いパフォーマンスを発揮する一方、大容量のデータを運用するのには向いていないことがわかります。結果として、実行可能なクエリなども制限されることになります。

RAMの容量問題以外にも、データのクエリがSQLではなくコマンドベースであることや、アプリケーションレイヤーでの追加処理が必要になるなど、SQLのシンプルさと比較して難しい点も挙げられます。

ユースケース

Redisの特徴を踏まえたうえで、ユースケースの紹介をさせていただきたいと思います。 よく見られるケースとしては、以下のようなものが挙げられます。

• ①キャッシング：セッションデータを保存、Webアプリとのやり取りを迅速に。
• ②リアルタイム分析：様々なソースからデータを集計・分析、ダッシュボードへの反映。
• ③メッセージキュー：バックグラウンドジョブやタスクキューの管理と非同期処理。
• ④Read制限：ユーザーが指定された時間内に行えるAPIコールの数を制限。

いずれも大きなデータ容量を必要とせず、かつ高いレスポンスを求められる処理であることがわかります。 今回は、キャッシングに注目します。

キャッシングは、いわば本に付箋を貼っていくような作業のことで、頻繁にアクセスされる重要なデータを素早く読み込むための機能です。これをRedisで行います。
具体的には、データベース本体はSSDに保存してSQLなどで管理を行います。Redisはアクセスの多いデータのみSSDからRAMにコピーを取って置きます。こうすることで、重要な処理を行う時に、RAMからデータを取って処理できるので、Webアプリケーションなどの高速化に貢献することができます。
また、RAMへ保存するデータ量も少量で済みます。

結論

今回は、高速な処理を実現するデータベースとして、Redisについて触れてみました。
RAMに保存&NoSQLという特徴から、一般的なデータベースと使い勝手が大きく異なる点が多いですが、「キビキビ動くWebアプリを作成してみたい！」という方は、一度触れてみてはいかがでしょうか。

前回の勉強会の記事： 【2024/03 勉強会】ペルソナで製品導入に向けたデザイン と AI・MLにおける音声処理・話者認識モデル の話