2021年5月11〜12日に開催された「AWS Summit Online 2021」で、楽天グループ グローバルテクノロジー統括部 Vice Group Managerの藤井博貴氏が登壇。「楽天の大規模AWSネットワークインフラの運用方法」と題して、「AWS Transit Gateway」導入の効果や、Ansibleを用いた業務自動化の取り組みを紹介した。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
1997年に創業し、楽天市場をはじめ、楽天カード、楽天銀行、楽天モバイルなど、楽天のエコシステムを通じて多岐にわたるサービスを提供している楽天グループ。コロナ禍で消費者行動が大きく変わる中、インターネットを中心にサービスを提供する同社にも多くのトラフィックが発生し、利用者、売り上げともに大きく伸びている状況だ。
ECから金融まで多岐にわたるサービスを展開する同社は、AWS(Amazon Web Services)の活用も積極的だ。「AWS Summit Online 2021」に登壇した藤井博貴氏(楽天グループ グローバルテクノロジー統括部 Vice Group Manager)は活用状況を次のように説明した。
「AWS利用中のサービスは大きく4つあります。ペイメントサービスにおける決済ゲートウェイやクレジットカードトークンシステム、フリマアプリの楽天ラクマ、楽天市場でのB2C(Business to Consumer)サービス、FinTechサービスの一部です。オンプレミスのデータセンターとAWSをAWS Direct Connectで接続し、AWS上でAmazon VPC(Virtual Private Cloud、以下VPC)を稼働させています。規模感としては、VPC内のバーチャルゲートウェイ(Virtual Private Gateway、以下VGW)が約10個、VPCは約20個、それらに30種類ほどの楽天サービスが載っている状況です」
オンプレミスのデータセンターと、データセンターからVGWまでの運用管理は、ネットワークエンジニアが担当し、VPC内のEC2をはじめとしたアプリケーション管理はサービスのユーザーであるそれぞれの事業部が担っている。
「ネットワークエンジニアは、データセンターからのインターネット接続や、データセンター間、データセンター内のネットワーク、カスタマールーターやAWS Direct Connect接続、VGWの管理など範囲が広く、稼働率も高い状況です」
こうした中で取り組んだのが、VGWと仮想インタフェース(VIF)経由で行っていたオンプレミスとVPCとの接続を、AWSトランジットゲートウェイ(Transit Gateway)経由に移行することだった。
楽天のネットワークの運用管理は、ユーザー(事業部)とネットワークエンジニアが責任を分有する形で行っているが、他にも担当者がいる。AWS Direct Connectの管理は、ユーザー向けに要件定義やコスト管理などをするテクニカルアカウントマネジャーが社内にいて、ユーザーからの依頼をアカウントマネジャーが受け、要件定義をしてネットワークエンジニアと一緒に内容を吟味する。
「アカウントマネジャーと一緒にVPCのアドレスの払い出しやネットワークの設計をして、内容が固まり次第、ネットワークエンジニアとユーザーが一緒に実作業に進むという流れです。この体制のメリットは、それぞれのパーティーがそれぞれの知識レベルで範囲内の役割を持ち、適材適所で業務をこなせることにあります。他にも、楽天の管理者を支えるAWSアカウントチームも存在し、新規サービスの提案や重要な作業への技術支援を受けています」(藤井氏)
Transit Gatewayへの移行に当たっては、それぞれの担当者の負担を減らすことに大きな狙いがあったという。Transit Gatewayは、VPCとオンプレミスネットワークを相互接続するために使用できるネットワークの中継ハブだ。中央ハブを介してVPCとオンプレミスネットワークを接続することで、ネットワークが簡素化され、VPC間の通信に関してはVPCピアリングを別途張る必要がなくなり、複雑なピア接続関係がなくなる。また、グローバルに展開することもでき、その場合、リージョン間ピア接続はAWSグローバルネットワークを使用してTransit Gatewayを相互接続する。
「Transit Gateway導入の動機は主に3つありました。1つ目は、ネットワークの簡素化です。VPCやピアリングの数が増えることで、通信制御や構成は複雑化します。オンプレミスのカスタマールーターとVGWのピア数を削減することで管理工数を削減する狙いがありました。2つ目は、迅速なリージョン間接続です。海外展開するサービスもあり、展開に当たって、リージョン間で共通の構成にしたり接続性を柔軟に提供したりする必要がありました。3つ目は、BCP(事業継続計画)構成の展開です。ネットワークインフラの提供者として、BCPを考慮した設計はますます重要になってきていました」(藤井氏)
導入に当たっては、導入検討、ギャップ分析、技術確認、検証試験、本番導入、本番移行という6つのフェーズに分けて進められた。このうち特に重要だったのが、技術確認と検証試験だったという。
「クラウドは共有リソースなので、オンプレミスのシステム導入時には考慮しなくてよかった制約事項が多くあり気を付ける必要があります。AWS側のクオーター(制限)を都度確認して、制限を考慮しながら設計して構成変更やネットワーク拡張を進めました。AWSアカウントチームに確認し、支援を受けながら必ず検証試験をすることを強くお勧めします」(藤井氏)
楽天が利用しているVPCは、歴史的ないきさつもあって、すでにTransit Gatewayで接続済みの既存VPCと、今回、移行対象となった仮想インタフェースと仮想プライベートゲートウェイで接続するVPCという2つのタイプが存在していた。オンプレミスのデータセンターのカスタマールーターは冗長化され、接続するDirect Connectも冗長化されている。移行は、(1)Transit Gateway向けに新規ルートマップの追加、(2)VGW向けルートマップの変更、(3)移行対象VPCのルートテーブル変更、既存プライベート仮想インタフェース削除、(5)Transit Gateway向け新規ルートマップ修正という流れで進めたという。
藤井氏は、Transit Gateway導入の効果を次のように説明した。
「VPC間のピアリング接続数によるネットワーク構成の簡素化を実現し、非常にシンプルで奇麗な構成になりました。特に、カスタマールーターとVGW間のピア数が減ることで、ネットワークエンジニアの作業工数の削減につながりました。ただ、弊社のように、複数のアカウントで同じリソースを共有するようなマルチアカウント環境の場合、Transit Gatewayでは、リソースの共有やVPCのアタッチの申請・承認など、ユーザーとネットワークエンジニアとの間でのボールの行き来が非常に多くなります。ここに余分な工数がかかるため、今後プロセスの見直しが必要だと感じています。BCPは、オンプレミスとAWS側でのダブルBCPが実現できました」(藤井氏)
楽天では、ネットワークエンジニアの定常業務の自動化にも力を入れており、その事例も紹介した。主な定常業務としては「オンプレミスのカスタマールーター設計構築運用」「Direct Connectの運用とコスト管理」「Transit GatewayとVGWの構築運用」「VPC向けIPアドレス管理」がある。
このうち、藤井氏が紹介したのは、VPC向けIPアドレス管理の自動化だ。VPC向けIPアドレス払い出しは、大きく「IPアドレスアサイン依頼受領」「IPアドレス管理データベース確認」「オンプレミス機器上のIPアドレス重複確認」「アサイン済みIPアドレス再鑑依頼」「IPアドレス管理データベース更新」となる。「JIRA」と「Infoblox」を活用していたが、これらは全て手動での作業だった。
「手動だったため、どこかの工程で漏れやヒューマンエラーが発生するとサービスに影響がでます。例えば、IPの重複やルーティングの設定が変わってしまうと最悪の場合、サービスが停止します。手動管理は、意識の高いエンジニアのモチベーションや向上心を低下される恐れもありました」(藤井氏)
自動化に当たっては、AnsibleとSlackを活用したという。Ansible Playbookで使用したいIPアドレスのセグメントやアドレス数、サブネット数などを定義し、値を変えたPlaybookを実行させるだけで、IPアドレスの払い出しからデータベースの最終更新までの自動化を実現した。
「今後は、ビジネスニーズに合わせて、Transit Gatewayをマルチリージョン化することや、大阪リージョンを活用した国内でのフルBCPの展開に取り組んでいく予定だ。さらに、AWS LambdaやAWS Step Functionsを使って、Transit GatewayのプレフィックスリストやVPCのアタッチメントのテンプレ化や自動化も検討していきたい」(藤井氏)
Copyright © ITmedia, Inc. All Rights Reserved.