「ファシリティ」「データ移行」「運用」　仮想基盤サーバーのリプレイスならではのインフラ設計とは

メール配信サービスシステム「配配メール」「クルメル」

小西智氏（以下、小西）：では、「仮想基盤サーバーのリプレイスに伴うインフラ設計」というテーマで、小西が発表いたします。

まずは自己紹介します。2002年からテクニカルエンジニアとして働き始めました。ラクスには、2019年にインフラエンジニアとして入社しました。現在は「配配メール」と「クルメル」のインフラの開発チームに所属しています。サービス運用と継続的な改善に取り組んでいます。

あと、好きなこととしては、DIYを趣味でやっています。始めたいことは陶器作りで、春から教室に通いたいと考えています。

軽くですが、サービスの紹介です。「配配メール」「クルメル」ともにメールの配信サービスシステムになっていまして、「配配メール」は、メルマガ配信や一斉メール配信をしています。「クルメル」は、API連携やメールリレーに対応したシステムです。

今回話す内容は、設計についてです。設計といっても、さまざまなことを検討して形にしていく必要があると思っていまして。基本の設計だったり詳細の設計、移行設計、運用設計など、いろいろなフェーズで設計を行い、各フェーズで設計した内容を問題なく実行できるようにする必要があると考えています。

今回は、仮想基盤サーバーのリプレイスを通じて、実際に行った設計の一部ではありますが、そこを紹介して、今後、サービス運用と継続的な改善につながる、設計について考えた内容を発表していきたいと思っています。

設計の目的

まず「設計」について考えてみました。先ほども言ったとおり、いろいろな設計があります。システム設計、ソフトウェアの設計、アプリケーションの設計、ネットワークの設計、データベースの設計、移行設計、運用設計などがあります。日々業務していく中で、インフラエンジニアとしては、いろいろな設計に携わっていくところが見てとれます。

設計の目的ですね。そこをちょっと考えてみました。要件を受けて実行・運用フェーズで問題が発生しないように機能を検討して準備するところと、要件をもとに設計書や仕様書などの資料を作成することでほかの方にも見える化するところが、設計の目的かなと考えました。

HCIの構成

では、実際の事例に沿って考えていきたいと思います。仮想基盤を構成するサーバーのリプレイスを実施しました。大きく2つの課題が存在していました。1つが「サーバーの老朽化に伴いメーカーのサポートが終了した」というところ、もう1つが「サービス拡大に伴って、今現状のサービスのリソースが不足してきていた」という、大きな2つですね。

実際の仮想基盤の構成としては、HCI（ハイパー・コンバージド・インフラ）を採用していまして、その中の数台のサーバーをリプレイスすることになりました。

実際のそのHCIの構成ですね。ちょっと簡単にですが、従来型の3Tier構成が「ストレージ」「スイッチ」「サーバー」という3段階の構成になっていたのですが、これらを1つのアプライアンスのサーバーで構成してシンプルな仮想化の基盤を作っているのがHCIの構成です。

今回の設計の概要なんですが、今回は一部のサーバーのリプレイスでもありまして、システム全体の設計については現行の設計内容を踏襲しています。

ファシリティの設計

今回、リプレイスならではの設計を見ていきたいと思います。まず1つ目としてはファシリティの設計。これは、データセンターにサーバーを設置しますので、そこの設計部分です。続きまして、データ移行の設計ですね。最後に運用の設計という3つで話を進めていきます。

まずファシリティの設計。今回、新規のサーバーを設置するだけでもいろいろな観点で設計する必要があります。そのデータセンターのラック内の電源の使用量とサーバーの保守性。あとはネットワークの帯域で考えていきます。

まずラック図が変更前／変更後で左と右に図があるのですが、ラックAのサーバー1番・2番をリプレイスするところで、新しいサーバーをラックAに入れたいんですけど、移行期間があるので、ラックのBにサーバーを入れます。

あと電源ですね。電源容量を設計する必要があるんですが、基本設計で決めた容量で推移するように新サーバーをラックBに搭載して、電源容量が計画内に収まるように設計しています。

続いてラックBに搭載する位置ですが、Bでもサーバーの保守性だったり、熱の対策の問題を考慮してマウント位置を決めたりしていかないといけません。既存のサーバーを上のほうに並べていますので、続けて6番の下に新1番・新2番と設置する設計です。

今回ラックB側に2台サーバーを追加するため、ラックAとBの間のネットワークの帯域を確保する必要があります。今回2台増えることによってサーバー台数が2倍になっているので、そこの通信の帯域を拡張・確保することと、サービスが拡大していることによって仮想マシン自体の台数も増えていることを踏まえて、ネットワークの構成を改めて設計しました。

データ移行の設計

続いて、データ移行の設計です。データ移行の設計としては、まず要件として「サービス停止なしで移行を完了させる」という要件がありましたので、単純に基盤サーバー1から基盤サーバーの新しいサーバー1番に移行するのは、仮想マシンなので問題なくいけます。サービス停止なしで問題なくいけます。

ただ、その移行の中で、新たな課題が見つかりまして。既存へサーバーパッチを適用する必要がありました。そのパッチを適用するにあたって、基盤サーバーの再起動が必要になるため、全停止しないといけません。

そうなった場合に、旧1番・旧2番はなくなるサーバーです。新1番・新2番に移行するのは問題ないですが、3番の仮想マシンを新1番・新2番に寄せて3番のメンテナンスをしないといけなくて、その配分をうまく分散して、順次基盤サーバーのパッチ適用を行いました。

運用設計

運用設計です。運用設計の中で、先ほどもあった偏りが仮想マシンにちょっとあります。「配配メール」「クルメル」の中でも複数のサーバーで構成されていまして、メールを作成するサーバー。共用のサーバーだったり専用のサーバーだったり。次にメールを配信するサーバーというのと、その配信したメールの結果を解析するサーバーと、あとはAPIの連携をするためのサーバーなど、さまざまな役割のサーバーが存在しています。

このサーバー群が新規で仮想マシンを作るときに、仮想基盤の空きリソースによって基盤のほうに作成していた関係で、ちょっと偏りが発生していました。その偏りに伴って処理が集中したことがあって、基盤の負荷がちょっと高くなるような問題がありました。絵で書いてあるとおり、緑のサーバーが偏っていたり、青のサーバーが寄っていたり、黄色のサーバーが寄っていたりという構成になっていました。

そこでサーバーの役割ごとにグループを分けて、各グループで平準化をしようと設計をしました。黄色が7台、オレンジ色が9台、青が8台、緑が11台、これ仮に置いているのですが、こういったところでグループを分けて4つの仮想基盤のサーバーに均等に分散することを考えると、黄色は1～2台、オレンジ色は2～3台第、青は2台、緑も2〜3台で分散させられます。

とはいえ、仮想マシンは役割によって使っているリソースが違っています。黄色のサーバーに関しては、4コア・8GBのメモリ、オレンジは4コア・4GBのメモリ、青は3コア・6GBのメモリ、緑は2コアで2GBのメモリで、いろいろなリソースで動いているため、単純に割って平準化することが難しくなっていました。

その①②を合わせて考えるとこの表になるのですが、こちらがCPUで割った分とメモリで割ったものとの合計ですね。そこを合わせて分散すると、こういった下のように平準化できました。

結果として、設計した内容を実施していき、無事にサーバーのリプレイスと増強を完了させられました。移行期間中にハードウェアの障害が発生したり、パッチを適用したりなど、いろいろな問題が起きたのですが、ふだん実施している業務の中で、実践している運用の計画がありますので、それを実行して障害を取り除き、スムーズな移行を進められました。

これからの設計について

それらを踏まえて「これからの設計について」をまとめています。インフラ構築はリプレイスとかプロジェクトがいろいろあると思うのですが、比較的ウォーターフォールで進めているようなことが多いなと。私自身もウォーターフォールのプロジェクトで進めている経験が多かったので。

ただ、システム運用という観点から見ると、品質の維持であったり、効率化を図ったりなど、問題の早期発見・解決といった、スピードが要求されるところがあります。

ですので、そのスピード感も重視する必要があるため、今後は、インフラエンジニアとしてオンプレ・クラウドの構築スキルも必要なのですが、柔軟に設計方針を変更したり、そのときの最適解を見つけて進化していくと。その最適解によっては、その設計方針そのものを変えて実施いく必要があると考えています。

以上です。

藤澤貴之氏（以下、藤澤）：：小西さん、ありがとうございました。

感想と質疑応答

池田智裕氏（以下、池田）：ありがとうございます。それでは質問というか感想みたいなところなのですが、「運用設計という考え方、今まではあまり意識していなかったな。今後の観点として心に留めておきます」というのがありました。

私も見ていて、なんかパズルみたいな感じがして、あれって組み立てるときには、「CPU〇〇は何台まで」みたいな感じで足していく感じになるんですかね。

小西：そうですね。想定している増加台数はもともと計画には入っていますので、分散はそれをベースにしています。

池田：ただ、3つまでいったら、4つ目はもうちょっと別のサーバーにしようとか、なんか同じ役割のものは2つか3つまで、みたいなルールで分散させていく感じなんですかね。

小西：そんなイメージですね。

池田：ありがとうございます。Twitterで1つ、「HCIを採用することのメリット・デメリットって何でしょうか？」という質問があります。

小西：HCIは統合されているので、運用管理がすごく楽になっていますね。今まで3Tierという構成だったとき、物理サーバーだったり物理的な機械が多いので、それに伴う障害だったりも発生しますので、HCIによってそういった障害はかなり減っているのがメリットですね。

藤澤：普通のいわゆる仮想基盤という意味だと、例えばそれぞれにサーバーが別の筐体としてボコボコあるんですが、HCIは要は広大なリソースがボワーンってあって、それを分け合うみたいな。

小西：そうですね。サーバーとしては複数台サーバーがあるんですが、それを1つのクラスタのような感じで管理していまして。

藤澤：それが個別のものというわけじゃなくて、全体が1つの管理ツールなどで管理されているという。

小西：そうですね。はい。

藤澤：なるほど、わかりました。ありがとうございます。そうですね、インフラエンジニアが今回どれぐらい参加されているのかちょっとわからないんですが、僕はわりとインフラ畑に疎い人間なので、この設計のところの電源などはわりと新鮮でしたけどね。

小西：なるほど。

藤澤：なんかストレージやメモリ、CPUなど、そのへんはだいたい想像できるんですが。「あっ、電源か」というのはちょっとあったんですけど。小西さん、電源ってイメージで言うと、なんか処理がバーっとリクエストが来たりして、高負荷になったりすると、やっぱり消費量とかも上がるんですか？

小西：上がりますね。はい。

藤澤：そのへんも考慮して、電源のマックスに対してどれぐらい割り当てるかみたいなのを決めていく感じになるんですか？

小西：そうですね。当然ラックには電源が引かれていて、その電源にもブレーカーがあって容量って決まっていますので、それを超えないということは考えないといけないので。

藤澤：なるほど。自作PCなどでグラボをメチャクチャ処理能力強いやつを挿すと、電源変えないといけないみたいなのがありますが、それも同じような考え方だと思います（笑）。

小西：はい。

池田：ちなみに先ほどの役割によって負荷が変わる話だったと思うんですが、やはりメール配信サーバーが一番負荷がかかったりしているんですか？

小西：そうですね。大量に当然配信をしますので、その配信が重なったりとかすると……。

池田：重なったりとかする？

小西：はい。高く。

池田：ですよね。だから、メール配信サーバーが1つの仮想サーバーにガーって集中していると、そこが電力もアクセスもバーって高くなってしまう恐れがあるということですよね。

小西：そうですね。

藤澤：今Twitterで「メールサービスならではのインフラ構築の難しさってありますか？」というご質問がきました。

小西：先ほどちょっとあったとおり、お客さんによって配信の時間ってけっこう重なってしまうことがあって。当然、お昼休みに配信されたりとか、あとは夕方に配信されたりというのがあるので、その瞬間的な配信に耐え得るように設計していかないといけないのは、メール配信ならではなのかなと。常時高いわけではなくて、瞬間的な対応をとらないといけないところですかね。

藤澤：そうか。お客さんの使い方によって特定のサーバーに処理が集まったりとか負荷が高まったりするのがあるっていうことですかね。

小西：そうですね。

藤澤：なるほどですね。ちなみに今日発表したのはオンプレの事例でしたけれど、弊社、サービスによってはパブリッククラウド、まぁAWSとかですね、採用しているようなケースなんかもあって、今日はオンプレについてのお話だったというところになります。さぁ、ほか、みなさんのなにかリアクションってありますかね？

池田：そうですね。メーカーのサポートが終了したサーバーというところで、「身に覚えのある話」という方が。この人はインフラ出身の方なんですかね。メーカーのサポートってどれぐらいで終了するものなんですか？

小西：そうですね。メーカーが発売して、その次期バージョンが出たら5年後とか7年後とか、そんなかたちでメーカーから出てきていますので。

池田：なるほど。新しいものが出てから5年ぐらいはあるだろうと。

小西：そうですね、メーカー保守はあると思っていますけど。

池田：なるほど。

藤澤：「インフラの設計という今まで触れたことのない分野なので、話を聞くのがおもしろい」といったリアクションをいただいていますね。あんまりインフラの話って表に出てこないことが多いですからね。

小西：そうですね。なかなか出てこないですね。

藤澤：わりと「AWSの使い方」みたいのは多いけど、「こう運用しています」みたいな話とかあんまり聞けないので。

池田：あと、インフラの話じゃないのですが、「迷惑メールに判定されたりしないのですか？」というのがあるんですけど、これはちょっと藤澤さんのほうから回答を。

藤澤：はい。判定されたりすることはあります。

池田：まぁ、ありますけど、なるべくされないようにIPを複数もったり、あまり集中して1秒間に何通以上は送らないとか、そういうふうな工夫をしたりして。あとは失敗したら、一定期間おいてから送信するとか、まぁいろいろな工夫をしています。

藤澤：そうですね。迷惑メールの判定って、例えばGmailならGoogle側がけっこうコントロールしたりするので、実際、何が理由で迷惑メールに判定されるとかがわからないところがかなりあったりします。なんかトライ&エラー的なところがあるんですが、一般的なところで言うと、詐欺っぽいような文章、「お金が儲かりますよ」みたいな、そういう迷惑メールになりそうな文面をお客さんから配信しないようにお願いしたりとか。

あとは、今、池田からちょっと述べさせてもらったような、そういうインフラのところで迷惑メールに判定されにくいような仕組みをかなりいろいろなところ、多岐にわたる取り組みがあったりして、たぶんそれだけで1時間ぐらい話すような内容になるので。ちょっと今日のところは今の簡単なさわりというようなところでご勘弁いただければ、というようなところでございます。そんなもんですかね。

池田：ですかね。はい。

藤澤：あ、「雲の向こうに任せていると意識を向けることが少ない分野だけど、オンプレミスの基盤構築の知識はやっぱり知っておいて損はないよね」と言う意見が。なんかクラウドを使っていくにしても、まぁそうですよね。

ちなみに小西さんはどうです？　たぶん両方業務で使っていると思うんですが、やっぱりパブリッククラウドを使う上でも、こういうオンプレの経験ってけっこう活きたりしている感じですか？

小西：そうですね。けっこう使いますね。

藤澤：勘どころみたいな？

小西：勘どころとか考え方とかがベースにないと。

藤澤：なるほど。では小西さん、どうもありがとうございました。

池田：ありがとうございました。

小西：ありがとうございました。