SAP HANAはインメモリーだからと言って運用管理面で特別なことはない

SAP HANAは今やOracle以外のほとんどのプラットフォームで稼働可能

SAP Tech JAMで「SAP HANA 運用管理のカンどころ」というテーマでSAP HANAの運用管理面について解説したのは、SAPジャパン プラットフォーム事業本部 プリンシパルソリューションアーキテクトの松舘 学氏だ。

「インメモリーデータベースは普通のデータベースとどこが違うのか。じつはインメモリーと言っても、あまり普通のデータベースとは変わりません」（松舘氏）

SAP HANAは基本的にアプライアンスで提供している。利用形態としてはオンプレミス、SAPが提供するクラウドの「SAP HANA Cloud Platform」、Amazon Web ServicesやMicrosoft Azureの上で利用するといったものがある。ハードウェアプラットフォームとしてはインテルとの協業が長く続いており、さらにIBMのPowerベースのマシンでも動くようになった。OSもSUSE Linuxに加えRed HatでもOKとなった。そういう意味では「Oracle以外のマシンでは動きます。今では400から500くらいの認定環境があります」とのことだ。

アプライアンス構成以外にも、自社データセンターの既存マシンで利用するテイラードデータセンターオプションの提供も始まっている。こちらはアプライアンスの固定的な構成に対しかなり自由度の高いものとなっている。最初はストレージを選択できるようにし、続いてCPU、ネットワークスイッチなどのリソースも選べるようになった。最新ではインテル Xeon E7 v3への対応も発表されており、並列処理性能が上がっているのでこれにリプレイスするだけでもかなりの性能向上が見込めそうだ。このように選択の幅が広がったことで開発検証の環境は（プロセッサに関する制約を守れば）「ほぼ自由に選択できるようになりました」と松舘氏は言う。

もちろん仮想化にも対応している。現状はVMware vSphereのみの対応で、KVMには未対応。vMotionなどの仮想化のメリットも利用できる。そのほか、ハードウェアベンダーの物理パーティションにも対応している。

「VMware vSphereはバージョン5.5に対応しています。これだと64 CPUコアでメモリーも1テラバイトまで、本番環境としては少し小さいかもしれません。とはいえバージョン6ももうすぐ使えるようになると思います。8ソケット対応で、これなら本番環境にも使えるでしょう」（松舘氏）

【参考記事】
既存ハードウェア環境への対応を拡大するプラットフォームとしてのSAP HANA
https://www.sapjp.com/blog/archives/11119

本番環境ならDatacenter Service Pointのタイミングで更新するのが安心

運用管理の側面から見ると、最新版であるSAP HANA 1.0 SPS 09からマルチテナントの機能に対応したのは大きな変化だ。マルチテナントデータベースコンテナはコンテナの単位ですべてが分離している。なので本番とテストの環境が一緒にあっても問題ない。コンテナごとに、ハードウェアの利用率を制御することも可能だ。

運用時に管理者が気にかけるのは、こういった新機能を含むパッチセットをどのタイミングで本番環境に適用するかだろう。

「最新のSPSが出たおよそ3カ月後に、Datacenter Service Pointというリリースが出ます。本番環境であれば、出たばかりの最新ではなくこれを適用するのが比較的安心かと思います。もちろんSPSをすぐに上げなくてもいいです。更新される前バージョンの最後のパッチについてはマイナーリリースの形で更新されるので、それを使い続けることもできます」（松舘氏）

もう1つ新機能として紹介されたのが「Dynamic Tiering」だ。

「これはアーカイビングと運用の中間的な機能です。データをHotとWarmにわけ、HotはインメモリーにWarmをカラムストアに入れます。今はこれを全自動ではできませんが、将来的にはルールに従って自動配置できるようになると思います」（松舘氏）

将来はHotに置くべきかWarmに退避すべきかを、管理者が意識する必要がなくなるだろうとのこと。この機能はSPS 09で追加されたが制限もある。Dynamic Tieringを使っている場合には、フェイルオーバーがマニュアルになってしまうのだ。また災害対策機能であるシステムレプリケーションも使えない。これらの弱点は、今後のSPSで改善される予定だ。

弱点もあるが着実に運用管理性は向上中

インメモリーデータベース、それもSAP HANAのようにすべてがインメモリーに載るアーキテクチャでは、データの永続性に不安を持つ声も聞こえる。SAP HANAではいわゆるコミットが走る処理が行われると、ログがストレージに書き込まれるので電源が落ちてもデータが消えることはない。とはいえ、再起動時にログからデータを読み込むとなると大変だ。そこでデータボリュームの形でもストレージに保持している。データボリュームとログを使うことで、「任意の復旧時点にリカバリー可能なポイントインタイムリカバリーにも対応しています」と松舘氏。

バックアップもインメモリーだからと言って特に変わらない。認定された3rdパーティーのバックアップツールなども利用でき、メモリーからバックアップサーバーのメモリーに直接書き込むといったことも可能だ。

インメモリーデータベースでは、バックアップ処理は基本的にオンラインバックアップになる。フルバックアップが基本となり、差分バックアップがとれないところは弱点だ。「こういった制限も新しいSPSで徐々に改善されてきます。顧客のRFPで作られる機能の○×表も以前は×が多くハラハラしましたが、今ではかなり安心して見ていられます」と松舘氏。バックアップやリカバリーの作業は、HANA StudioのGUIから実行できる。

データベースを管理していれば、拡張性も気になるところだ。

「SAP S/4HANAなどは、なるべくシングル構成で大きなサーバーで動かすのがいいでしょう。一方でデータウェアハウスのようなものは、スケールアウトで拡張性が高いものを選ぶべきです。112台まで並べて使えるので、100テラバイトを越えるような大きなものも容易に運用できます」（松舘氏）

また災害対策では距離が50kmくらいまでは同期によるシステムレプリケーションが可能だ。100kmを越えるような場合には非同期となる。どちらを選ぶかはシステムの重要度に応じ考える必要がある。この他にもストレージのレプリケーション機能なども利用できる。残念ながら現状ではログシッピングに対応していない。これも今後のSPSで機能使いされてくるのではとのこと。

運用状況のモニタリングなどはHANA Studioで行える。システム管理のユーザーインターフェイスはSAP Fioriになっているので、iPadなどのタブレットなどでも利用可能だ。今後はiPhone版のアプリケーションも提供される予定がある。

「SAP HANAの運用は特別難しいところはありません。なのでSAP Business Suiteのデータベースとしてだけでなく、ぜひともプラットフォームとしてSAP HANAを使って欲しいです」（松舘氏）

枯れた老舗のデータベースに比べれば、SAP HANAはまだまだ「かゆいところに手が届かない」こともあるだろう。とはいえ、着実に運用管理性は向上しているようだ。ユーザーが欲していて今はまだSAP HANAに足りないところについても、SAPはしっかりと認識しているようだ。なので必要な機能や制限の改善は、順次実施されるはず。もし速くこの機能が欲しいといったことがあるならば、SAPの担当者なりに強力にプッシュしてみるのもアリだろう。