【IIJ GIOの裏側を語る#8】クラウドサービスに対応した仮想ネットワーク基盤

カテゴリー: インフラストラクチャーP2, 技術情報, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第8回です。

今回は、IIJネットワーク本部の和佐が「クラウドサービスに対応した仮想ネットワーク基盤」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
ネットワーク本部 ネットワークサービス部
和佐 好智

「第8回:クラウドサービスに対応した仮想ネットワーク基盤」

クラウドサービスに対応した仮想ネットワーク基盤

弊社のクラウドサービス「IIJ GIOインフラストラクチャーP2」をはじめとするクラウドリソース群への接続手段として、インターネットのみでは昨今の市場ニーズを満たすことはできません。
セキュリティが担保された閉域IP網を介して各クラウドリソース及びオンプレミスが相互接続されるべきであり、またクラウドらしい物理的な配置にとらわれない振る舞いが可能なネットワークが求められます。

今回はそれらを実現するIIJの仮想ネットワーク基盤と、それを提供するサービスについて、ご紹介します。

お客様専用のバックボーンの提供

IIJ GIOプライベートバックボーンサービスは、マルチクラウドを想定しているため、IIJのクラウドサービス群にとどまらず、他社のクラウドサービス(Microsoft Azure等)含めて相互接続することができるサービスです。MPLS/L3VPNによるマルチテナントのL3閉域IP網を作り出し、お客さま専用のプライベートネットワークとして提供しています。

図1:サービス構成例

上記の図は、イメージをつかむための抽象図です。中央にあるIIJ GIOプライベートバックボーンサービスが、様々なクラウドサービスやオンプレミスを相互接続しています。
2017年4月現在、18個のサービス間を接続することが可能になっており、お客様ごとに必要なリソースをプライベートネットワークの中に接続することが出来ます。
これを具体化すると、以下のような構造になります。
あらかじめ物理的な接続を行っている IIJ GIO や、Microsoft Azure, Amazon AWS などのクラウドリソースなどでは、論理的な設定作業を行うだけで、各リソース間のプライベートネットワークを構築することが可能になっています。そこに、お客様拠点との物理的な接続や、Internet VPN での接続を行うことで、お客様のプライベートネットワークの一部としてご利用になれます。

図2:仮想ネットワークアーキテクチャ

上記の図では、末端にあるVLANの色単位で”網”が作られます。
MPLSによるL3VPNで色ごとの網を構築し、経路情報はVRFを利用し網単位に分けたうえで、MP-BGPによって網内に伝達します。

これらは各色の単位でそれぞれ別(マルチテナント)の閉域IP網 とみなすことができます。また物理的立地に依存しない網構築を実現することができます。
たとえばあるPEは東京にあり、あるPEは大阪にあったとしても、各VLANに接続された機器からはIP的に1 hopで到達しているようにみえるので、1つのルータがクラウド上にあるイメージで、直感的に利用いただくことができます。 特別な設定も必要ありません。

基盤構成

上記のような広域のオーバーレイネットワークを構築するには、品質の高いアンダーレイネットワークが必要です。ここが弱いと、”クラウドらしい、物理的立地にとらわれない仮想ネットワーク” が破たんします。上述のように東京と大阪が1 hopに見えると言っても、アンダーレイ的には様々な機器を経由しているので、これが遅いと、逆に “1 hopあたりの遅延が大きい低品質のネットワーク”に見えてしまいます。

IIJ では、日本初の商用インターネットサービスプロバイダーとして培ってきたネットワークインフラを運用するノウハウがあり、これを活かした基盤構築と運用を行っています。

今回ご紹介したIIJ GIOプライベートバックボーンサービスの基盤もインターネットを支えるバックボーンと同じ基盤上に仮想ネットワーク基盤を構築することで、インターネットバックボーンと同様に高い品質を保っています。

図3.基盤アーキテクチャ

次回は、大規模インフラの安定運用について解説します。

今後の連載予定

【IIJ GIOの裏側を語る#7】オブジェクトストレージ設計上のポイント

カテゴリー: ストレージ, 技術情報, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第7回です。

今回は、IIJクラウド本部の飯田が「オブジェクトストレージ設計上のポイント」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス2部
飯田 拓哉

「第7回:オブジェクトストレージ設計上のポイント」

はじめに

近年SDS(Software Defined Storage)という言葉が注目されています。SDSと呼ばれる製品/サービスには様々な種類のものがありますが、弊社でも「ストレージ&アナリシスサービス」(以下、本サービスとします)という名称でオブジェクトストレージサービスを提供しています。本稿では本サービスの設計やアーキテクチャについて紹介します。

自社での設計/実装

本サービスのシステムは、多くの構成要素が自社内で設計/実装されています。具体的には、サービスとして公開しているAPIや内部のメタデータ管理機能などについて、弊社のエンジニアがスクラッチから設計/実装を行っています。これは、サービス仕様と実装に対して自社でのコントロールを手放さないことで、万一の問題発生時や将来的な機能拡張などに際して対応手段の選択肢を増やすことを狙ったもので、これまでのところ期待通りの運用となっています。

設計コンセプト

システムの形容として「スケーラブルで柔軟な」という表現を見掛けますが、本サービスシステムでも同様の課題について幾つかの角度から検討を行いました。ここでは、スケーラビリティについて一点、柔軟性について一点、どのようにアプローチしたのかという点について紹介します。

スケーラビリティ:「数」への対処

大規模ストレージの現実的なデータ利用場面を考えると、単体で数TBを超えるような巨大なデータが大量に発生するケースは多くはありません。つまり、大規模ストレージを設計/実装する上でスケーラビリティを考慮する際には、いかに巨大な「数」(「容量」ではなく)を捌くか?という課題について検討することになります。たとえば普通のファイルシステムであれば、数十万件から数百万件程度のファイル数でもlsコマンドの結果取得に長時間掛かるなど、事実上の使用不能状態に陥る場合がありますが、弊社のオブジェクトストレージが想定したスケールは数百TBから数PB規模であり、件数ベースでは数億から数十億件となります。

そこで本サービスの設計では、物理データのファイル名など各種情報を高速なNoSQL系のDBへ格納して別管理とし、ストレージシステムには単純に「データを保存する」機能のみを担当させることで、stat系の操作による負荷を可能な限りストレージシステムからオフロードしました。

上記内容について、実際に本サービスで格納されているデータの1億件程度のサンプリングを行った結果としても99パーセンタイルが10MB辺り(最大値は数TB程度)になっており、前提となる想定(小さなデータが大量)は間違っていなかったと思います。なお、ここで述べた考え方を前提とした場合に、仮に「大きなストレージを少数用意」してしまうと結局個々のストレージが数をさばき切れなくなり、結果的に「性質の異なる『数の問題』を複数同時に抱える」ことになります。反対に「小規模なストレージを沢山用意」すると性能的には有利になりますが、設備規模に比例するコストが上昇するため提供価格の上昇を招きます。

以上のことから、実際のサイジングや設備設計においてはコストを勘案しながら「落とし所を探る」作業がもう一つのポイントとなりました。

柔軟性:抽象化層による機能の分離

元々オブジェクトストレージは一般的なファイルシステムと異なる概念で構成されているため、何らかのマッピング機構を用意することが適切と思われました。また、このシステムはサービス提供を目的としたシステムで、市場ニーズやテクノロジーの変化などに応じて機能や規模を変化させられる必要がありました。

そこで、NoSQLに格納したメタ情報とその管理系コンポーネントを抽象化層とし、物理的なストレージ上にあるデータの状態と外部から論理的に参照されるオブジェクトの状態が、メタ情報管理系を介してマッピングされる構造としました。この構造により、データストアは外部に公開するAPI仕様から分離して可換性を持ち、同時にフロントAPIではデータストアの機能や制限に影響されることの無い設計自由度を確保しました。

比較的良く見掛ける「抽象化層を挟むことで疎結合な系を実現しようとするアプローチ」で、それをコンポーネント単位のレベルで適用しています。当初の意図は基本的に実現できていますが、公開APIの機能が「データのIO」でありストレージへの直接アクセスが論理的に不可避であるため、この点について対策が必要でした。性能維持や信頼性など他の要件とのトレードオフを検討した上で、最終的に公開APIの中に抽象化層を設けることで回避することになりました。

具体的には公開APIのロジックが操作するデータ入出力部分を抽象化層とし、ロジックから分離したIOの実装系にストレージへの依存性を封入しました。これはこれで上手く機能し、抽象化層を挟み込んだことでフィルタ系の機能拡張等も可能になるなど副次的な効果も得られました。

システムアーキテクチャ

上で述べたような考え方は分散システムとしての構成を暗黙的に示唆しており、実際本システムは分散システムとして設計されました。全体としては垂直分散型のシステムで各コンポーネントは原則的にREST APIで連携するものとしました。分散システムの設計では一貫性維持や可用性確保など、いわゆるCAP定理としてまとめられるような課題から、ロック問題のような比較的実装に近いレベルの課題まで、様々な課題について検討することになります。本項では、それらの検討内容から二つの要素について紹介します。

コンポーネント/API粒度

分散システムで各コンポーネントやコンポーネントが提供するAPIの粒度の設計を誤ると、一貫性の維持が極端に複雑になったり、予見し難い設計レベルでの不具合を作り込んだりするリスクがあります。前述の通りコンポーネント間はREST APIで連携する想定としたため、システム全体を従来型の(RDBMSが実装しているような)同期的なトランザクションで実装することはできませんでした。

そこで一貫性については結果整合性を前提とし、大きなトランザクション単位の検討からスタートし、非同期的なロールバック処理や排他制御などが簡便に実現可能な箇所でトランザクションを分割した上で、分割後の各単位は従来型の同期的なトランザクションで扱うこととしました。つまり、同期的なトランザクションを非同期的な結果整合性維持の仕組みで結合する戦略です。

これにより、同期的且つシンプルな実装と局所化された(分割箇所に集中させた)結果整合性ロジックから成る「系全体としての結果整合性」を実現しました。

コンポーネント/APIの粒度設計の考え方を端的に言うと「結果整合性の考え方で行くけど、野放図にやると破綻するから局所化した」ということになります。この件に関しては、前提として「結果整合性の考え方を導入することで実現される柔軟性はシステム全体として実現されるべきものであって、必ずしも構成要素の何もかもが非同期化/疎結合化されている必要は無い」という考え方がありました。

結局「何のために、どこを柔軟にしたいのか?」という問に答えながら、堅くする部分と柔らかくする部分を決めて行くことが設計作業の重要なポイントの一つ、ということかと思います。

追記型データ操作

そもそもの考え方として、同期的なロック操作自体を極力減らそう(できればゼロに)という考え方から、システムで扱うデータ全般について原則的に追記型の操作のみを行うものとしました。つまり、論理的に同じデータの更新が生じた際には、更新後データを追加して更新前データを無効化することで論理的な更新とする考え方です。正データの判定はタイムスタンプで行い、常に最新のものを正と判断します。主だった入出力系には可能な限り(処理が複雑化し過ぎない限り)適用していますが、全ての操作に100%適用できた訳では無く、単純な形での追記型操作が適用できなかった処理については非同期化で回避しました。

具体的には、操作自体を従来型の同期的な上書き更新操作とした上で、処理自体を非同期バッチで実行するなどの対応であり、無効となった過去データの永続的な削除処理などがこれに該当しました。

場合によりロック操作を伴うトランザクション管理は必要なものですが、大規模にスケールさせる必要があるシステムでは遅効性の劇薬になり得ます。ロックにまつわる問題が厄介な理由の一つは「修正が困難なタイミングで初めて顕在化する傾向がある」ことです。それらの問題は、規模が大きくなったり利用が増加したりしたタイミングで競合待ちの遅延やデッドロックなどの形で表出し、気付いた時には抜本的な対策を行い難いという事態になりがちです。そこで「対処が困難なら無くしてしまえ!」と取り組んだのが追記型の考え方でした。

今回のの設計では結果的に完全撲滅には至りませんでしたが、少なくとも問題を局所化し非常に限定的なものへ追い込むことができたと思います。

終わりに

今回はサービスシステム設計の比較的初期段階で行われたコンセプトやアーキテクチャの検討をご紹介しました。本稿で述べたような内容は抽象的で、実装上の細かなテクニックなどに比べると意義が判り難い面があるかも知れませんが、或る程度以上の規模のソフトウェアをチームで開発する際には大変重要なものであると考え、今回ご紹介させて頂きました。お読み下さった方の何かのご参考になれば幸いです。

今後の連載予定

IIJパートナーフォーラム2017を開催しました!

カテゴリー: Microsoft, イベント, パートナー
このエントリーをはてなブックマークに追加

今回は、2017年3月13日に開催した「IIJパートナーフォーラム2017」のレポートをお届けします。

このIIJパートナーフォーラムは、IIJ GIO、IIJ Omnibus、モバイル、LaIT(中小企業向け再販ブランド)などのIIJのビジネスパートナー様をお招きし、最新のIIJサービス情報の共有や、2016年度を通してサービス拡販に特にご尽力いただいた企業を表彰するイベントです。

IIJのパートナービジネス戦略

IIJ 勝栄二郎まずはじめに、IIJ代表取締役社長 勝栄二郎より、パートナーの皆様にご挨拶申し上げました。
IIJは今回パートナープログラムを一新し、より密な情報連携が可能となるパートナーポータルのリニューアルや、新たな再販商材のラインアップを公開しました。IIJはこうしたパートナーネットワークを通じ、より広い範囲でお客様のニーズにお応えできる体制を構築していきます。

基調講演「変革の時代のリーダーシップ」

日本マイクロソフト 樋口泰行様フォーラムの基調講演には、日本マイクロソフト代表執行役会長(当時)の樋口泰行氏にご登壇いただきました。講演のテーマは「リーダーシップ」です。

日本では数少ない“プロの経営者”といわれる樋口氏の経歴や、前職のダイエーで経営再建を担われたストーリーを臨場感たっぷりに語られました。
さらに、樋口氏が2017年度4月1日付で専務役員に就任したパナソニックへの思い(樋口氏は新卒で松下電器産業に入社)もお話しいただきました。

「IIJ Partner of the Year 2016」の発表

フォーラム後半では、2016年度に特に素晴らしい実績を残しIIJビジネスの拡大
にご尽力いただいたパートナー様を表彰する「IIJ Partner of the Year 2016」
アワードの表彰式が行われました。

今年は多くのパートナー様の中から、5社が受賞されました。

2016年度 IIJパートナーアワードを受賞された皆さま

2016年度 IIJパートナーアワードを受賞された皆さま

受賞された5社のパートナー様をご紹介いたします。

Partner of the Year

株式会社メディアテック 様

長年のパートナーシップをさらに発展し、IIJ GIOとIIJ Omnibusの展開を強力に推進、IIJのクラウドサービス拡大に多大なご協力をいただきました。

IIJ GIOアワード

アビームコンサルティング株式会社 様

ユーザの業務アプリケーションを支える「Abeam Cloud」の基盤にIIJ GIOを採用、IIJ GIOの売上拡大に大きくご協力いただきました。

IIJ Omnibusサービスアワード

株式会社USEN 様

法人向けICTソリューション「USEN GATE 02」のラインアップとしてIIJ Omnibusを積極的に活用いただき、多くの案件を獲得されました。

LaITアワード

アイ・ティー・エックス株式会社 様

IIJのネットワーク機器を遠隔管理する独自技術『SACM』を活用した、マネージドVPNサービス「MORA VPN Zero-Con」を多くのユーザに導入されました。

モバイルアワード

パナソニック株式会社 様

IIJのMVNOプラットフォームを活用し自社のモバイルサービスを構築、IoTをはじめ様々な場面にモバイルサービスを提供されました。

今後もIIJはパートナー様と様々な分野で連携し、共にビジネスを成長させていくために、より深いパートナーシップを推進していきたいと思っています。
新たなパートナープログラムのもと、より強力な支援体制を整えていきますので、どうぞよろしくお願いいたします。

また、IIJパートナープログラムにご興味のあるお客様は、担当営業またはお問い合わせフォームまでご連絡ください。

(IIJパートナー事務局)

【IIJ GIOの裏側を語る#6】 オンデマンドを実現するベアメタル制御

カテゴリー: インフラストラクチャーP2, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第6回です。

解説者は、IIJクラウド本部の山内です。

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス2部
山内 徹

「第6回:オンデマンドを実現するベアメタル制御」

IIJ GIOインフラストラクチャーP2(IIJ GIO P2)のプライベートリソースではベアメタルサーバを提供していますが、今回はその仕組みについて解説します。

以下のステップで、ベアメタルサーバ制御の自動化を行っています。

  1. ベアメタルクラウドを実現するシステム構成
  2. OSインストールの準備
  3. OSのインストール
  4. Windowsのライセンス・アクティベーション
  5. OSインストール後の処理

1. ベアメタルクラウドを実現するシステム構成

ベアメタルクラウドを実現するにあたり、IIJ GIO P2プライベートリソースではFigure 1の構成になっています。スイッチに在庫としてのベアメタルサーバが接続されており、お客様から利用のお申込みがあると、未使用の在庫から適当なベアメタルサーバが選択されます。

Figure1

制御サーバ OSのインストールや設定など、ベアメタルサーバを制御するサーバ
ベアメタルサーバ お客様占有の物理サーバ。お客様からのお申し込みに応じて、OSのインストールや必要な設定が行われる
スイッチ ベアメタルサーバが接続されているネットワークスイッチ。必要に応じてベアメタルサーバ間の接続を繋ぎ変えることができる

2. OSインストールの準備

次に、サーバにOSがインストールされますが、LinuxかWindowsか、対象のOSに応じてベアメタルサーバの接続されているスイッチのポートVLANを設定します。

Figure 2

制御サーバのAPIが呼ばれると、制御サーバはインストールの準備を開始します。
まずは、インストールに必要なファイルを用意します。Linuxの場合はkickstartファイルを、Windowsの場合はインストールスクリプトを生成します。申し込み内容に応じたOSの設定はそれぞれのファイルに記述されています。

制御サーバは指定のベアメタルサーバをIPMI(Intelligent Platform Management Interface:ネットワークを通じて、コンピューターのハードウェアを操作する標準規格)を使って起動します。起動時にベアメタルサーバはPXE(Preboot eXecution Environment:インテル社が策定した、ネットワークブートの規格)ブートするよう設定されています。この時、接続されているスイッチのポートのVLANIDによって、DHCPリレーエージェントを利用し、DHCPの要求先(ここではPXEサーバと共用)を切り替えています。

先ほど、インストール対象がLinuxとWindowsに応じたポートVLANを設定すると書きましたが、これにより、OSによって異なる制御サーバが認識されるわけです(Figure 3)。

Figure 3

3. OSのインストール

起動してしばらくするとPXEブートによりIPアドレスなどのネットワーク情報が割り当てられ、それぞれのPXEサーバ(制御サーバと兼用)からNBP(Network Boot Program)をダウンロードします。

Figure 4


ここからLinuxとWindowsで動作が異なります。
Linuxの場合、OSインストールAPIによって作成されたkickstartファイルの記述に応じて、バージョンに適したOSのイメージを制御サーバよりhttpで取得し、インストールを開始します。

一方、Windowsの場合はNBPのダウンロードの後、Windows PE(Windows Preinstall Environment)という、PXEブート用のWindowsをダウンロードします。Windows PEは初期設定用のスクリプトを起動し、制御サーバからインストールするバージョンに応じたインストールイメージおよび設定スクリプトを取得し、ローカルのディスクに保存した後、再起動します。
再起動によりインストールスクリプトが起動し、ローカルディスクに保存したインストールイメージを使用してインストールを開始します。

4. Windowsのライセンス・アクティベーション

インストール処理の中で、Windowsのライセンス・アクティベーションを行います。
Windowsのアクティベーションには電話認証のほか、KMSやMAKなどいくつかの方法がありますが、P2プライベートリソースでは、直接インターネット上のマイクロソフトの認証サイトを使ってアクティベーションを行います。
インターネットへの接続には、制御サーバと同じネットワーク上にプロキシサーバが設置されており、ここを介してマイクロソフトの認証サイトへ接続し、ライセンス・アクティベーションを行います(Figure 5)。

Figure 5

5. OSインストール後の処理

Linux/Windows共に、制御サーバはインストールが完了するまで待ち続け、完了を検知するとAPIを呼び出したサーバに対して完了した旨を通知します。
OSのインストールが完了したのち、ポートVLANからお客様専用のVLAN(タグVLAN)へお客様のサーバが接続されているスイッチの設定を変更します。(OS側のタグVLANの設定は、インストール処理の中で行います)これにより、管理ゲートウェイへの接続および、お客様のサーバ同士の通信は可能になりますが、制御サーバとお客様のサーバとの相互接続は絶たれます。

Figure 6

一通りの設定が完了した後、インストールが正しく行われたかの検査を行います。
制御サーバの検査APIが呼ばれると、Linuxの場合はSSHを、Windowsの場合はWinRMを使用してお引渡し前のお客様のサーバへ接続し、検査コマンドを実行することで各種検査を行います。

ただし、スイッチの設定が変わりお客様のサーバへ直接アクセスするルートはなくなっていますので、今度はお客様のサーバに提供される管理ゲートウェイを経由して検査を行います。
管理ゲートウェイはリバースプロキシの役割も兼ねており、制御サーバからお客様のサーバへ接続することはできますが、お客様のサーバから管理ゲートウェイを経由して制御サーバへ接続することはできません。

Figure 7

検査はOSの設定のほか、ハードウェアの構成などに対しても併せて行います。検査で問題がないことが確認されたら完了です。完了した旨を通知し、お客様にお渡しします。


次回は、オブジェクトストレージ設計上のポイントについて解説します。

IIJ GIOサービスアップデート(2017年2月分)- IIJ GIO P2 「ISO/IEC 27017:2015」 取得しました。

カテゴリー: インフラストラクチャーP2, サービスアップデート
このエントリーをはてなブックマークに追加

こんにちは。サービス企画部の鍋倉です。

3月に入り寒暖を繰り返しつつ徐々に春に近づいていっている感覚ですが、野球日本代表の寒さを一気に吹き飛ばす熱戦が始まっています。
3/15現在 6連勝中!このまま勢いによって決勝まで勝ち抜けるよう、応援しましょう!

今月の、IIJ GIOのリリース・アップデート情報をお届けします。

2017年2月のIIJ GIOサービス更新情報

IIJ GIOインフラストラクチャーP2

クラウドセキュリティの国際規格「ISO/IEC 27017:2015」を取得

受領日: 2017/1/27

IIJ GIOインフラストラクチャーP2はこの度、クラウドサービスの情報セキュリティ対策に関する国際規格である「ISO/IEC 27017:2015」の認証を第三者機関より取得しました。詳細はIIJ GIOのセキュリティページをご覧ください。

IIJはセキュリティに配慮し、これからも安全・安心してご利用いただけるクラウドサービスを提供してまいります。

IIJサブスクリプションライセンス

LifeKeeper/DataKeeperを提供開始

リリース日: 2017/2/8

クラウドやオンプレミスの環境で利用可能なソフトウェア製品のライセンスを月額料金にて提供しています。
この度、HA(High Availability)クラスタ/データレプリケーション製品である、サイオステクノロジー社の「LifeKeeper/DataKeeper」の提供を開始しました。
LifeKeeper/DataKeeper製品では、通常の共有ディスク(SAN等)によるHAクラスタのほか、ローカルディスクのレプリケーション機能が用意されており、共有ディスク(SAN等)不要でスムーズかつ安価にHA環境を導入いただくことができます。

また、基本的な設定を専用のGUIで行うことが可能で、高度なHA構成を簡単な操作で導入できます。

本製品の詳細については、LifeKeeper/DataKeeper製品紹介ページ(サイオステクノロジー株式会社)をご参照ください。

また、本製品の導入については、弊社営業またはお問い合わせフォームまでお問い合わせください。

(クラウド本部 サービス企画部 鍋倉)