1G.第1世代 POSレジを統合せよ

1G 第1世代、2007年〜

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPU数は1、ないしは2系統搭載されていた。

x64アーキテクチャ	周波数（GHz）	2ndCache（MB）	HyperTransport	Core	TDP
Opteron 260HE	1.6	1 x2	1GHz	2	55
Opteron 280	2.4	1 x2	1GHz	2	85

概要

InfiniCloudの記念すべきプライベートクラウドの第1弾は、とある会社のPOSレジを統合管理するためのインフラストラクチャとして設計された。

内容は、POSレジ自体からインターネット経由、HTTPSでWebAPI接続をし、管理システムはWebベースで行うというもの。アプリケーション層はJava Servletで作成されたので、今では特に珍しい仕様ではない(※当社も当時はアプリケーションからインフラストラクチャまで全てインテグレーションするのが業務範囲であったため)。

このときのモダンな開発技法は「Easy of Development」だ。コンピュータの性能は、どんどん上がるので、ソフトウェアは手軽にフレームワークを使い、メモリ最適化や速度最適化など、気にせずに作ろうという考え方が浸透しはじめた。裏返せば、物理サーバの速度が上昇し始めたので、一般的な会社の一般的なワークロードが、サーバを限界まで使い切ることは難しい状態になったことを意味している。

システム設計手法にもよるが、サーバは役割に応じて、あるいはミドルウェアに応じてハードウェアが分かれており、ウェブサーバ、アプリケーションサーバ、データベース、APIサーバ、メールサーバ等、役割に応じてゲートウェイサーバ等、様々なサーバが用意される。冗長化を考えるとこれらは2倍になる。

しかし、これだけの物理サーバを用意することは、中々難しい。

サーバを買う資金も必要だが、データセンターのラック費用にも跳ね返る。そこで、1つの物理サーバに複数のシステムをなるべく同居したいという顧客要望が発生することになる。技術的には可能だし、現実的には他社が作る多くのシステムでは、この実装が多くみられた。

ただ問題はシステムの分界点が見えにくくなってしまうことだ。どのシステムがどのように互いに連携するかわかりにくくなるため、いざシステムを分割するとしても中々難しくなってしまう。

そこで、この基盤では、何らかの仮想化を使う必要が発生したという形だ。

サービス自体は「クラウド」という名前がまだ浸透する前のサービスであったことから、Virtual Data Center Service(バーチャルデータセンターサービス)と位置づけられた。

これを「プライベートではなく共有にしたもの」は、当社では既に専用サーバサービス「Phase2Server」があったことから、これに関連付けられ「Phase2Server Lite」（フェイズツーサーバーライト）と命名された。

CPU

CPUにAMD Opteron K8 revE（Italy）を搭載。これはまず、64ビットCPUであること。そして同時期のIntel CPUよりも消費電力が少なく、かつDual Coreプロセッサをいち早く搭載したことが大きい。デュアルソケットマシンなら合計4コアを実現することも採用のポイントだった。マルチプロセッサアーキテクチャも、SMPではなくccNUMAを採用することで、1物理CPUあたりのメモリバンドが6.4GBytes/sec、1コンピューティングノードあたり12.8GBytes/secと、高性能を誇る。

仮想化技術(ハイパバイザなど)

仮想化エンジンを選ぶにあたり、最初に候補に挙がったのはXenだ、XenはVer 3になったところだが、この時代に使われるCPUの仮想化支援機能(AMD-V)はまだ十分なものとは言えず、NPT(Nested Page Tables)が実装されていなかった(その後、AMD-VにはRVIという名前で実装される)。XenでNPTが無い場合、メモリアクセスが遅くなり、これを回避するにはハイパバイザコール(PVモード)を利用する必要がある。そこでPVモードのXenも検討されたが、一方で、仮想OSのカーネルを全てをオンメモリで確保するためには、それなりの搭載メモリが必要になってしまう。

そこで、カーネルを単一にするプロセスパーティショニングの一種である、コンテナ型技術を採用することに決定した。

コンテナ型技術は、現在はKubernetesやDockerなどで数多く使われるメジャーな技術だが、当時はFreeBSDのjail、Linuxでは実装の一部としてOpenVZなどがあるだけで、オープンな実装が少なかった。またリソースの制限機能が少ない。そこで、コンテナ型ながらリソースの制限機能の実装や高い隔離性を実現した、Sun Solaris 10のSolaris Container（zone）を採用(※わかりにくいがこの当時のSolaris Containerは、ZoneとSolaris Resource ManagerをあわせてContainerと言われていた)。Sun Solarisには、いち早くコンテナ機能が採用されており、エンタープライズの実績も伴っていたためだ。

ストレージ

このジェネレーションで導入された技術は、3-Tier型のストレージだ。3-Tier型仮想化システムでは、ストレージが要となる。そのため高価なストレージ製品を買うのが一般的だが、当時の当社では投資できるものがなかったため、独自に、SolarisのZFSとNFSv3を利用し、仮想サーバのイメージをNFS上に格納した。

コンテナの技術特質上、ライブマイグレーションはできないが、様々な工夫をするとオフラインマイグレーションができる。当社独自で作られたそれらのオーケストレーションソフトウェアスタックを、「DimensionPlus」という仮想化支援ミドルウェアとして構築。コンテナはconductorと言われる管理システムにより、管理されていた。