システム技術部 基盤グループの高橋 佑太です。
前回の記事「自社データセンターを移転してインフラを大刷新した話～前編～」をご覧になっていない方は、そちらも合わせて御覧ください。
自社データセンターを移転してインフラを大刷新した話～前篇～ のリンク
前編では、３つの経営上の課題と、それをデータセンターの移転ならびにシステム基盤の総見直しをすることで解決したことをご紹介しました。当社いにおいて、最大規模のプロジェクトであり、期間・コストも非常に大掛かりなものでありました。しかもそれを極力内製で行うという。
後編では、一部ではありますがどの様に工夫しプロジェクトを推進したのかを、各担当からご紹介いたします。
- 推進：プロジェクト推進方法を改善を繰り返しつづけスピードと品質を両立
- 品質：世界最高レベルのデータセンターへ
- 棚卸：ファシリティーセンター内のラック・配線から拘りながら外部接続の一斉棚卸し
- サーバー：最も台数が多く広大でありレガシーとの戦いとなった基盤
- ネットワーク ー異なるデータセンターを１つに。セキュリティを考慮しトポロジーから見直し
- 最後に：戦いを終えて
まずはじめにプロジェクト推進についてのご紹介です。
推進：プロジェクト推進方法を改善を繰り返しつづけスピードと品質を両立
（執筆:システム技術部 アプリ基盤グループ 吉井 章）
はじめに
本プロジェクトは、当社でも過去最大クラスの規模となる一大プロジェクトとなりました。 プロジェクトの根幹には、ブラックボックス化している部分も含め可視化し、プロジェクト完了後も、スピード・品質を両立した改善を進めるため、現社内メンバーで可能な限りプロジェクトを遂行することを掲げました。
こういった背景の中、教科書に書いたようなウォータフォールでのプロジェクト推進と管理だけではなく、プロジェクトの特性にあった管理を検討・実施しました。プロジェクト中にも常に管理方法の最適化についてメンバーと議論を重ね、管理プロセスそのものも改善していく様に推進しました。
一部ですが、プロジェクト管理で工夫した点と効果についてご紹介します。
ワーキンググループの作成
本プロジェクトではまず、いわゆるレイヤーごとに下記の 4 つのワーキンググループ (以下、WG)に作成し、それぞれにメンバーをアサインしました。
- サーバ基盤 WG
- ネットワーク WG
- データベース WG
- アプリケーション WG
今回は新規サービス開発や取引所等の制度対応ではなかっため、インフラを軸としたグループ分割をし、横串で話し合いなら深堀り調査や計画・設計を進めていきました。
プロジェクト初期は上記 WG で進めていたのですが、プロジェクトの規模が大きく、WG 間の認識合わせが難しいなどの課題がありました。そのため、レイヤーごとの WG は廃止し、下記のように移行タイミングごとの WG へと再編を行いました。
- 全体移行統括 WG
- 重要データベース移行 WG
- 執行系システム移行 WG
- 勘定系システム移行 WG
- その他移行 WG
- 旧データセンタ撤退 WG
レイヤーごとの WG では認識齟齬などが発生しやすい状態でしたが、移行タイミングごとの WG に再編成したことで、同じ目標に向かって業務を進めやすくなりました。
脱Excel:Backlogでの集中タスク管理
プロジェクト初期では、ハードウェアベンダーと共同で Excel や Microsoft Project でのタスク・ガントチャート管理をしていました。 しかしプロジェクト中期になってくると、タスクが徐々に増加していき 、Excel では管理しきれないという課題が出てきました。そこで、全体移行統括 WG にて、横断的なタスク管理の実施行うために Backlog でのタスク集約・管理を徹底する方針としました。 議論中の些細な課題・決め事は残さずチケット化することで、実施した対応と履歴が残り、誰でも後から参照できるようになりました。
また、チケット数やバーンダウンなど実際の"量"が可視化できたため、現場のみならず、ステークホルダーへの状況説明・共有に大いに役に立ちました。 あわせて、チケットの集計やサマリなどは Backlog API を活用しました。これによって、全体のさらなる効率化にも繋がったと考えます。
エントリー方式による日次進捗会
本プロジェクト中期からは日次で進捗確認会を設定し、常に状況を全体で共有・管理する手法を採用しました。本会議は、単純な進捗管理だけではなく、プロジェクトメンバーが課題やリスクを抱え込まずに、「何か課題が出ても、参加して相談すればなんとかなる」という空気・状況を醸成することも目的としていました。そのため、日次進捗会には以下のルールを設定し、推進していきました。
- プロジェクトリーダーおよび全体移行統括 WG メンバは常に参加し、ファシリテーションを行う。
- 毎日の会議ごとに Backlog チケットを作成する（Backlog API を活用し自動化）
- プロジェクトメンバーは事前に議題（新たな課題など）をアジェンダに登録する。
- 会議開始後の飛び込み相談も可とする。ただし、FIFO 方式で後回し。
- 議題はその場で必要なメンバーを招集し、議論を行う。
- 議題に関係の無いメンバーは、会議に参加しつつも自身の作業を進めて良い。
- 議論の中で新たな課題やタスクが発生した場合は、その場で新規チケットを作成する。
- その日の議題がなくなるまで、4.～ 7.を繰り返す。
本プロジェクトはコロナ禍の真っ只中で進行していたこともあり、参画メンバーのほとんどがテレワークでの勤務となっていました。そのため、日次進捗会はすべてオンライン会議で実施する必要がありました。
従来の対面会議では、必要メンバー全員が会議室に集まって行う必要があり、自身に関係のない話題であったとしても、拘束時間が発生してしまいました。一方で本プロジェクトでは、Web 上での開催であることを活かし、自身に関係のない話題のときは、会議に参加しつつも自身のタスクを進められる仕組みとし、会議参加に対するハードルが下がるようにしました。
結果として、本プロジェクトを完了させることができた要因のひとつとして、この日次進捗会が挙げられると思います。
おわりに
本プロジェクトでは、極力管理タスクを減らしつつ、課題の吸い上げ、共有を密に行うことでスピーディーかつ効率の良い進捗管理体制を整えました。これらの管理体制におけるプロジェクト推進は、当社が開発を内製化しており、全員がプレイヤーでもあったことから、成立したのではないかと考えています。
次は、データセンター他についてです
品質：世界最高レベルのデータセンターへ
執筆:システム技術部 SREグループ 岩井 大輔）
世界最高レベルのデータセンターの採用
本案件の中枢をになるデータセンターファシリティでは、まずデータセンター自体の品質向上に着目しています。具体的には、JDCC（日本データセンター協会）が定義するデータセンターの品質指標を元に、自然災害（津波・河川氾濫や大地震、伴う大規模停電）における対策の水準を検討し、結果、最高水準であるティア4であるアット東京データセンターを採用しました。
有人オペルームの見直し
セキュリティを踏まえフルリモートでの監視・運用ではなく、有人によるセンター常駐型のオペレーションチームを構築しています。チームメンバーが24時間快適に就業可能なオペレーションルーム構築にあたり、休憩ルームを確保し快適に休める場所を確保するといった、従業員にたいして快適な職場環境の提供をいたしました。
センター内セキュリティの最適化
センター内部の監視カメラシステムをアプライアンスから、IAサーバのアーキテクチャへ変更することで、可用性確保の観点で柔軟でかつ、録画ファイル提出が求められるシチュエーションで専用の再生ツールが不要な汎用的なフォーマット（mp4）へのエクスポートができる柔軟性の高いシステムへ変更しました。
また当社特徴として、入退出の認証システムに静脈認証ではなく学習型AI内蔵型顔認証システムを取り入れています。開業以来、光彩、三次元顔認識と先進的なソリューション導入してきましたがいよいよAI技術を取り入れ、認識率、判定速度の向上に成功しています。このような非接触型での生体認証システムによる恩恵はコロナ禍においてより享受できているものと考えています。
高いセキュリティと低いコストでHDD/SSD処分
約4,000本あったHDD/SSDなどの記憶装置は情報処分専業業者様と協業し、消磁＋物理破壊の二重対処を行いセキュアかつ低コストで処分をいたしました。処置されたHDD/SSDはマテリアルリサイクルされ環境へ配慮も怠らず対応いたしました。
環境への配慮
忘れてはならない旧データセンターのクロージングにおいては、不要となったラック、ケーブル、サーバ・ハードウェアの大半を有価物として処分することで、廃棄コストを抑えつつ、SDGsのリサイクル項目に沿った社会貢献を実現しています。
次は、センター内のラック・配線他についてです。
棚卸：ファシリティーセンター内のラック・配線から拘りながら外部接続の一斉棚卸し
（執筆:システム技術部 基盤グループ 高橋 知美）
旧データセンターの課題の１つに、ラック構成・配線設計・回線管理がありました。20年間の間に継ぎ足しでラックが増え、配線が増え、回線が増え…（セキュアな通信をする性質上、各取引先との専用線が多く、、回線は管理簿上では他拠点も含めて約300弱(！)）。それらが縦横無尽に行き交い複雑化していました。このような状況では回線撤去をするにもお客様サービスに影響を与える可能性もあり、容易に撤去作業ができず端末のみ撤去、配線は残置するしかない状況でした。 また、別の課題で回線手配の納期もモノによりますが3か月はみておく必要があり、短縮が難しいとはわかりつつももどかしい思いを抱えていました。 この課題をアット東京データセンターではどのように整理・解決したかをご紹介します。
ファシリティ・ラック収容の効率化
アット東京データセンターでは電源系統や配線系統が2系統に分かれており、分離ポリシーや機能ごとに正/副でラックを分ける設計にしました。また、ファシリティ作業をする際に直観的に判断し、ミスが起きないようにするために2対のラックの正面向かって左が正系、右が副系にしました。小さなことですが、非常にわかりやすくなったと感じています。また、配線経路をシンプルに、ラック間のケーブルの渡りを極力なくす配置にしました。
回線収容ラックの新設
アット東京データセンターデータセンタでは新たに回線終端装置(ONU)のみを収容するラックを新設しました。ONUラックにはONUを縦に10本ほど収容できる専用の棚板を設置し、収容効率を上げました。視認性・保守性があがりました。また、回線業者さんの作業範囲もIDFラック↔ONUラック間に限られるので他ラック・システムへの干渉のリスクをなくすことができました。
回線納期短縮（構内配線の利用）の実現
アット東京データセンターの構内配線サービスを利用し、最短納期6営業日で対向との回線を敷設することができるようになりました。アット東京データセンター内にラック・収容ポイントを持つ取引先やキャリア（アット東京データセンターの信頼性・特徴から金融系の会社が多いです！）やメガクラウドとも接続ポイントがあるため、利用頻度は高いです。物理結線直結、単純に接続先との距離が大幅に縮まったことで1msecでも早い、安定した通信ができるようになりました。また、構内配線サービスでは受け渡し方法でパッチ渡しができるため、ONUを設置する場所を節約できるというメリットもありました。
最終的にデータセンタ移転案件がおわって、最終的な回線数は約160本になりました。（新川では太古の使ってるかわからないお化け回線・契約も相当数あったのです・・）当社の対外接続環境は50以上あり、それを一同におさめたONUラックはなかなか見ごたえのあるものに仕上がったと感じています。これからもお客様が求めるサービスをより早く提供できるように、足回りの回線調達をスピーディに行っていきたいです。
次は、サーバ他についてです。
サーバー：最も台数が多く広大でありレガシーとの戦いとなった基盤
執筆:システム技術部 基盤グループ 新貝 興、澁谷 理希）
データセンター移転に伴う基盤最適化
サーバーインフラについて、既に当グループの新貝 興から、別のブログで紹介がありますのでそちらをご参照ください。
Ansible活用による作業効率化へ
当案件では、基本リフトアンドシフトであり、以下に安全に移設できるか？が焦点でしたが、一方で、既存運用の効率化目的として、Ansibleの導入をしました。
今まではホスト名、IPアドレスの設定やドメイン参加などサーバ個別の設定など手動で設定している箇所があり、設定作業に加えて確認にも手間がかかってしまっていました。また手動での設定には担当者の操作ミス等により予期しない変更も付きまとっていましたが、Ansibleで自動化することに必要な項目に正しい設定が自動でできるようになりました。
今はまだ、OSのバージョンによってテンプレートを準備する形をとっており、Windows2012R2、Windows2016、CentOSの一部バージョンのみを対象とし、また、ミドルウェア系は監視ソフトウェアやDB接続のソフトウェアも一部に限定して、Ansibleでのインストールを行っていましたが、今後はさらなるOS種別の拡充とともに、様々ななミドルウェアもAnsibleで自動で構築できるようチャレンジしていきたいと考えています。
次は、ネットワーク他についてです。
ネットワーク ー異なるデータセンターを１つに。セキュリティを考慮しトポロジーから見直し
（執筆:システム技術部 基盤グループ 山崎 貴裕）
20年間の間に蓄積された旧データセンターのネットワークトポロジーは継ぎ接ぎ型のネットワークのため、物理論理含めネットワーク全体が複雑化しており管理も大変でした。これら旧データセンターのネットワークをアット東京データセンターに全て移転するプロジェクト自体がチャレンジであったのですが、本ブログではその中でも印象深い出来事や技術スタックについて語っていこうと思います。
やっぱり、ネットワークトポロジーのグランドデザインを描きたい
アット東京データセンターに作り上げるネットワーク基盤は新規基盤になるため、グランドデザインを描く必要があると思っていました。空想論ではなく、設計ポリシーや実装ポリシーを統一できる構成を意識して描きました。
設計ポリシー
当社が考える設計ポリシーとは、目的にもとづいた設計を実現するために順守すべきポリシーです。今回の目的は、グランドデザインに描いたネットワークトポロジーを目指すことであって、それを実現するために順守すべきポリシーをいくつか取り決めしました。
- 分離ポリシー
顧客サービス提供環境（本番面）、社内サービス提供環境（社内面）、開発または運用に必要な環境（開発面/運用面）など主たる用途による環境分離、セキュリティ区分を設けることで、セキュリティポリシー管理策や運用管理策などの取り決めがしやすくなり、作業効率化にもつながります。
例えば、面間で発生する通信は必ず面間ファイアウォールを経由するポリシーとすることで、他面間の通信要件とセキュリティポリシーを一元管理できます（下図 他面間通信の概要）。
- 集約ポリシー
コストパフォーマンスを最大化するための手段となり、機器点数を削減し、機器性能を最大限活用する設計は、構成をシンプルにします。機器のコスト効率向上だけでなく、障害ポイントの発見を容易にし、管理工数を削減します。
例えば、本番面、社内面のサーバ収容スイッチの機器性能を最大限活用し、機器のコスト効率向上のため、１つのネットワーク機器に対して仮想スイッチ機能を導入し、分離ポリシーにもとづきリソース分割しています（下図「仮想スイッチ技術概要」を参照）。
- ルール化ポリシー
システムやその構成要素を適切に配置判断するための基準です。判断基準の明確化は、設計のスピードを向上させ、柔軟な変更と迅速な拡張が可能になります。
例えば、取引先ごとに必要な接続環境をそれ専用の接続エリアとして用意しておくことで、新規取引先が増えた場合に接続点の配置に悩まずに済みます。また、専用の接続エリアは実装ポリシーを定めているため、継ぎ接ぎ型のネットワークより格段と設計のスピードが向上します。
実装ポリシー
続いて、実装ポリシーとは、設計ポリシーにもとづいて非機能要件を定めることです（これ自体はどこの企業でも同じと思いますが）。
分離ポリシーにもとづく非機能要件
当社における本番面は、顧客サービス提供環境です。ネット証券として株式の売買に求められるレイテンシーは高いものになります。そういった顧客サービス提供に関連するシステムの導入の場合、低レイテンシーを実現する環境（250nsec以下）そのものにシステムを構築するといった実装ポリシーを定めています。集約ポリシーにもとづく非機能要件
上述した仮想スイッチ機能の他にVRF機能を利用しています。VRFは、異なる仮想ネットワークに対して個別のルーティングテーブルを維持する技術です。設計ポリシーで分離した面間通信において、他サイトとの通信を実現するためにVRFを利用してセキュリティレベルを保っています（という非機能要件を取り決めています）。 ここでいう他サイトは、社内サービス利用環境（オフィスネットワーク）を指しています。他サイトからの通信はVRFによって社内面としての通信として識別される必要があり、他面通信が必要な要件については必ず面間ファイアウォールを経由させます。ルール化ポリシーにもとづく非機能要件
取引先ごとに必要な接続環境をそれ専用の接続エリアとして用意しており、さらに機能要件的に共通な取引先との接続にはHub-and-Spokeモデルを利用することとしています。同様の要件で取引先が増えれば、網内接続を増やすだけであとは既存の拠点との接続で使用している設計ベースで柔軟に拠点追加が可能です。
ここまでは、いわゆる当社の内部システムに関するコアネットワークな部分のお話でしたが、次は、当社の顧客サービスの「顔」ともなるお客様インターネット環境についてのネットワーク話になります。
お客様インターネット環境はレイテンシーに合わせて高度なセキュリティ対策の実装が必要
システムの安全性や堅牢性については、データセンターなど物理的なロケーションや設備仕様だけでなくセキュリティ対策についても同様の条件が求められる時代です。 そのうえ、当社ではコストについての意識も高くもっており、低コストでありながらレイテンシーに強くセキュリティ対策についてもワールドワイドでサービス展開の実績が多いキャリアを選定しました。
当社が求めるサービス品質保証制度（SLA）
当社がお客様インターネット環境に求めるSLAは、可用性（上位ISPとの接続保証があること）、往復遅延時間（国内バックボーンネットワーク全体のRTT値）、パケット損失率、障害検知時の通知速度です。正直なところ、比較検討したどのキャリアも全て当社要件はクリアしていました。ですが、SLAの数値は各社異なる部分がおおく、より当社にとってメリットのあるキャリアを選定した経緯があります。
高度なインターネットセキュリティ対策
ここでいうインターネットセキュリティ対策は、私たちインフラチームで導入しているセキュリティ対策を指しており、具体的には、DDoS、WAF、IDS/IPS、Firewallです。
当社は過去、2017年にDDoS攻撃を受けたことがあります。この教訓からもDDoS対策には高額なコストがかかっていました。
変な話かもしれませんが、コストを下げつつ、旧データセンターと同等以上のDDoS対策可能なサービスを模索していたところ、結果的に旧データセンター時のTCOを約36%削減することに成功し、SLAおよびセキュリティ対策の要件についてもクリアするマネージドサービスに出会うことができています。
そのマネージドサービスに含まれるDDoS対策サービスの特徴について一部ご紹介します。
- ワールドワイドに展開される大規模ネットワークの各所にDDoS対策装置が分散配置され、 より攻撃元の近いところでDDoS攻撃を遮断可能 （ラストワンマイルの帯域を食いつぶされるリスクをより低減できる）
- 上記で求めるレイテンシーに加え、高度なセキュリティ対策サービス（SOC）をワンストップで提供してくれる。
- 最大帯域幅（bps）のみならず、ショートパケット（pps）、HTTPリクエスト（rps）などを利用したDDoS攻撃についても対策可能
- 国別フィルターなどの細かいシグネチャブロックなどにも対応可能
- 最大のポイントとして、DDoS検知後に当社オペレーションによる手動ミチゲーションが可能
最後になりますが、アット東京データセンター移転プロジェクトを進めるにあたって、移行フェーズを必ず踏むことになりますが、サーバ移行を簡易化するためにL2延伸（OTV）技術を利用したところに触れて終わりたいと思います。
全て新規にサーバ作り直す？いえ、V2VとP2Vを活用して移行の簡易化を図りたい
アット東京データセンター移転プロジェクトにおけるサーバの移行方式としてV2VとP2Vを採用することになっていました。ネットワーク観点だとIPアドレスはそのままにMACアドレスのみ変わるイメージです。 そのため、旧データセンターとは離れたロケーションであるアット東京データセンターにおいても、旧データセンター側にあるサブネットを利用できるようにするためにはL2延伸技術を利用する必要がありました。
L2延伸技術（OTV）のメリット
サーバの移行方式に合わせて、LANをサイト間に跨って延伸することができるうえに、MACルーティングによるVLAN拡張が可能であったことも採用に至った理由です。 当然、アット東京データセンターではVLAN IDを新規に設計している訳ですが、旧データセンターで使用しているVLAN IDとは異なるものであってもシームレスな変換が可能です。 また、L2延伸のため異なるサイト間に跨ってSTPを管理する必要性があるように思いますが、OTVは各サイトが独自のSTPを実行するため、ネットワークワイドなSTP管理は不要のためこの点も安心材料の１つでした。OTV技術の難しいところ
例え話になりますが、サーバAのMACアドレスをサイトAから学習していたとします。何らかの理由（ネットワーク障害、サーバ障害によるvMotionなど）でサーバAのMACアドレスをサイトBから学習しなおすケースが発生したとします。 この場合、ネットワークの構成条件によっては、サーバAから自発的なパケットを発出するか、上位スイッチのMACアドレスをクリアするかMACアドレスのエイジアウトを待つかしなければ、通信を復旧させることができない点が難しいところです。当社の場合は、サーバからの自発パケットによって、通信が復旧させることを前提としていました。
もう１つは、OTVによるオーバーヘッドが発生する点です。サイト間のサーバ間通信は、L2によるフレーム転送になりますが、OTV技術を挟むと当該フレームをIPヘッダでカプセル化する動作が追加されます。この分のオーバーヘッドは、通常のイーサネットのMTU値を超えることになるため、フラグメントが発生する要因になります。 これを解決するための手段として、OTVのOverlayインターフェイスに対してMSS値を設定する方法とオーバーヘッドのかかる途中経路のインターフェイスMTU値をジャンボフレーム化する方法です。前者の場合、オーバーヘッド分のMSS値が減少するため、結果的にスループットが下がる傾向にありますが、後者の場合は通常のイーサネットフレームのMTU値を最大限活用できるため、ネットワークワイドにL2ネットワークを展開できるメリットがあります。当社は後者の選択肢をとりました。
アット東京データセンタープロジェクトを完遂する上では、ファシリティ、サーバ、DB、アプリケーション各レイヤーとの関連性を整理しながら進めることがいちばん重要であったのではないかと思います。
このプロジェクト経験した教訓を活かして、今後も安定したサービスをお客様に提供できるよう努めていきたいと思います。
最後に：戦いを終えて
いかがでしたでしょうか。当案件で行った数々の工夫の一端についてご紹介させていただきました。 最後になりますが、プロジェクト戦い終え我々システム技術部メンバ各位は、他に代えがたい経験を得て、各位の自信・知見・達成感に繋がり、それが今後の当社のさらなる発展へのモチベーションへ繋がったと考えています。
そんな我々システム技術部では一緒に働く仲間を募集しています。 私が所属している システム技術部 基盤グループでは、システム基盤のモダナイゼーションをミッションとし、走攻守を掲げ、「走：スピードに拘る」、「攻：最新技術に拘る」、「守：品質に拘る」ことをモットーに、オンプレミス・クラウド両基盤を提供しています。
