Slide 1

Slide 1 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ©2021 RAKUS Co., Ltd. 仮想基盤サーバのリプレイスに 伴うインフラ設計 株式会社ラクス インフラ開発部 小西 智

Slide 2

Slide 2 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 小西 智(こにし さとし) 2002年に独立系の総合ITベンダーに入社、テクニカルエンジニアとして従事。 2018年にIT関連企業に入社、インフラエンジニアとして従事。 2019年にインフラエンジニアとしてラクスに入社。 現在は、「配配メール」「クルメル」を担当するインフラ開発チームに所属し、サービス運用と継続 的な改善に取り組んでいます。 好きなこと:DIY 始めたい事:陶器作り(春から教室に通います!!) 自己紹介

Slide 3

Slide 3 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 商材紹介 配配メールとは メルマガ配信・一斉メール配信サービス「配配メール」 メールマーケティングを もっと効果的に。もっとラクに。 クルメルとは API連携、メールリレー対応のメール配信システム

Slide 4

Slide 4 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 話すこと ひと言で「設計」といっても様々な事を検討し、形にする必要があると考 えています。基本設計・詳細設計・移行設計・運用設計などの各フェーズ での設計を行い、問題なく実行できるようにする必要があります。 今回は、仮想基盤サーバのリプレイスを通じて実際に行った設計の一部を ご紹介し、その中で経験した内容を踏まえ、これからの設計について考え た内容を発表いたします。

Slide 5

Slide 5 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 「設計」について考えてみた ひと言で「設計」といっても様々なものが対象になります。 例を挙げると以下のような設計があります。 システム設計、ソフトウェア設計、アプリケーション設計 ネットワーク設計、データベース設計、移行設計、運用設計… 日々の業務内容から、インフラエンジニアとして多くの設計にかかわって いく必要があるという事が分かります。

Slide 6

Slide 6 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 設計の目的 ・要件を受けて実行・運用フェーズで問題が発生しないように 機能を検討して準備する。 ・要件をもとに設計書や仕様書などの資料を作成することで見える化する。

Slide 7

Slide 7 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 事例 仮想基盤を構成するサーバのリプレイスを実施 大きく以下の2点の課題が発生していました。 • サーバの老朽化に伴いメーカのサポートが終了 • サービス拡大に伴うリソース不足 構成としては、HCI(ハイパーコンバージドインフラ)を採用しており、 その中の数台のサーバをリプレイスすることになりました。

Slide 8

Slide 8 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. HCI(ハイパーコンバージドインフラ)とは 〇従来の3Tier構成(ストレージ・ストレージネットワーク・サーバ)とは 異なり、これらを1つのアプライアンスとしてサーバのみで構成されるシ ンプルな仮想化インフラのことです。 【3Tier型】 ハイパーバイザー サーバ ストレージスイッチ ストレージ VM 【HCI】 ハイパーバイザー サーバ ディスク VM VM VM VM VM

Slide 9

Slide 9 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 設計の概要 一部のサーバのリプレイスのため、システム全体の設計については現行の 設計内容を踏襲しています。 今回は、リプレイスならではの設計を見ていきます。 ・ファシリティの設計(データセンター内の設計) ・データ移行の設計 ・運用の設計

Slide 10

Slide 10 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ファシリティの設計

Slide 11

Slide 11 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ファシリティの設計 新規のサーバを設置するだけでも様々な観点で設計する必要があります。 次の3つの内容を踏まえて設計を行いました。 ・ラックの電源使用量(可用性) ・サーバの保守性 ・ネットワーク帯域(拡張性)

Slide 12

Slide 12 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ファシリティの設計 ~ラックの電源使用量(可用性)~ ラックAの2台のサーバ(★)をリプレイスする場合でも、 移行期間が発生するため、サーバを並行稼働させる必要がある。 ラック内の電源容量は、計画内に抑える 設計をする。 【変更前】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 【変更後】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 新サーバ #1 ★ 新サーバ #2 ★ ※ラック構成図はイメージです。

Slide 13

Slide 13 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ラックBのレイアウトも保守性と基本設計(ポリシー)を考慮して、 搭載位置を設計する必要がある。 サーバの熱対策と保守・メンテナンスの 際の作業効率を考慮し、ラックの マウント位置を設計する。 ファシリティの設計 ~サーバの保守性~ 【変更前】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 【変更後】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 新サーバ #1 ★ 新サーバ #2 ★ ※ラック構成図はイメージです。

Slide 14

Slide 14 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ラックBにサーバを追加することで、ラックA-B間の帯域が十分確保できて いることを確認する。 また、将来の拡張性も考慮する。 ラックBのサーバ台数が2倍になり、 通信量が増加することと、 サービス拡大による仮想マシンの 台数が大幅に増加している事を 考慮して再設計する。 ファシリティの設計 ~ネットワーク帯域(拡張性)~ 【変更前】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 【変更後】 ラックA ラックB サーバ #1 ★ サーバ #2 ★ サーバ #3 サーバ #4 SW #2 SW #1 サーバ サーバ #5 サーバ #6 SW #4 SW #3 新サーバ #1 ★ 新サーバ #2 ★ ※ラック構成図はイメージです。

Slide 15

Slide 15 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. データ移行の設計

Slide 16

Slide 16 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. データ移行の設計 要件:サービス停止なしで移行を完了させる。 仮想マシンは稼働中でも サーバ間の移動が可能なため、 サービス停止なしの移行は問題なし。 リプレイス リプレイス

Slide 17

Slide 17 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 新たな要件 既存サーバへパッチを適用する。 パッチ適用にサーバの再起動が必要! メンテナンス対象の仮想マシンを 新サーバに2台へ分散して サーバ#3へパッチ適用する。 他のサーバについても順次パッチ適用を実施。 運用上の課題が 見つかる データ移行の設計 分散 分散 メンテナンス

Slide 18

Slide 18 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 運用設計

Slide 19

Slide 19 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 運用設計 課題:仮想マシンの偏りがある。 配配メール/クルメルでも複数のサーバで構成されている。 メール作成サーバ(共用サーバ、専用サーバ)、メール配信サーバ、 メール配信の解析サーバ、APIサーバ、… 新規に仮想マシンを構築する際、基盤サーバの空きリソースによって仮想マシンを作成していたため、 サーバの役割で偏りが発生していました。そのため、負荷が集中するときがありました。 そこで、次の観点で対策を検討しました。

Slide 20

Slide 20 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ①仮想マシンの役割ごとにグループを分けて、各グループで平準化する 7台 ⇒ 各基盤サーバ 1~2台 9台 ⇒ 各基盤サーバ 2~3台 8台 ⇒ 各基盤サーバ 2 台 11台 ⇒ 各基盤サーバ 2~3台 運用設計 VM VM VM VM

Slide 21

Slide 21 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ②各仮想マシンのリソースで平準化する。 全体で使用するリソースの合計をサーバ台数分で割ると、 基盤サーバ1台あたり、CPU:110÷4≒27.5 メモリ:162÷4≒40.5 とな るように配置する設計としました。 運用設計 仮想マシン 台数 1台あたり CPU[コア] CPU 合計[コア] 1台あたり メモリ [GB] メモリ 合計[GB] VM 7 4 28 8 56 VM 9 4 36 4 36 VM 8 3 24 6 48 VM 11 2 22 2 22 合計 35 110 162

Slide 22

Slide 22 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. ①役割グループによる平準化 →サーバの用途毎にグループを分けて偏りをなくす ②マシンリソースによる平準化 →全体の使用量から平均値を取り、偏りをなくす CPUやメモリなどの違いによる偏りが発生しないように考慮する 仮想マシンの再配置を実施 運用設計

Slide 23

Slide 23 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 結果とまとめ

Slide 24

Slide 24 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. 結果 設計した内容を実行していき、無事サーバのリプレイスと増強を完了させ ることができました。 移行期間中に様々な障害が発生しましたが、普段の業務で実践している運 用計画を実行することで、障害を取り除き、スムーズな移行を進める事が 出来ました。

Slide 25

Slide 25 text

#RAKUSMeetup ©2021 RAKUS Co., Ltd. これからの設計について インフラ構築やリプレイスなどのプロジェクトでは、比較的ウォーター フォールで進める事が多いと思います。 しかし、システム運用では品質の維持であったり、効率化を図ったり、問 題の早期発見・解決などスピードが要求されます。 インフラエンジニアとして、オンプレ・クラウドの構築スキルも必要です が、柔軟に設計方針を変更したり、その時の最適解を見つけて進化してい く必要があると考えています。