ユニクロが語る、AWSクラウド導入で得た7つのベストプラクティス

ユニクロのAWS活用を4つのポイントで解説

福田慧人氏（以下、福田）：皆さんこんにちは。皆さんお忙しい中、本日はお集まりいただいてありがとうございます。

たくさんセッションがパラレルで走っている中、ファーストリテイリングセッションを選んでいただいて貴重なお時間をいただいているので、本日は皆さんに本当に有益な情報を提供できるように頑張らせていただこうと思ってます。

それではさっそく始めさせていただきます。まずは自己紹介のほうからさせていただきます。

自分は福田と申します。ファーストリテイリングに入っていま2年半経ったぐらいなんですけども、リードテクニカルアーキテクトとしてやらせていただいてます。主にはコンシューマ系のサービスですね。

デジタル系のサービスなんですけどもモバイルのサービスだとか、あとは最近だとO2Oみたいなところ。あとはプラットフォーム系だとか、インフラからアーキテクチャまでフルスタックでいろいろ見させていただいてます。

荒賢一郎氏（以下、荒）：皆さんこんにちは。ファーストリテイリングの荒と申します。今日はよろしくお願いいたします。

私、インフラストラクチャー＆コミュニケーションサービスリードということで、主にエンタープライズのインフラということでビジネスアプリケーションのアーキテクチャインフラに加えて、WANとか弊社、洋服を売る仕事ですので店舗やオフィスのネットワークだったりとか、あとはアクティブディレクティブとかメールとか、コーポレートインフラストラクチャに加えて、ボイスのICTの技術を主に担当しております。よろしくお願いいたします。

福田：まずはファーストリテイリング、会社の概要から始まっちゃうんですけど。こちらKeynoteに出ていただいた方は弊社玉置のほうからお話もあったと思うんですけども、ファーストリテイリングというとやっぱりユニクロだとかGUのイメージは強いです。ただ弊社実はいろんなアパレルのブランド持ってます。

ほとんどは海外のブランドなんですけども、わかっていただきたいのはユニクロ、GU以外にもファーストリテイリングはたくさんのアパレルのブランドを持ってます。海外展開してるんですっていうところ。

こちらもKeynoteでシェアありましたけど、ざっくりいくと去年の数字としては1.4兆円弱。従業員の数も9万人弱。あとは店の数もどんどん増えてます。サービスを提供している国としてももう20以上の国。要はかなりグローバルにビジネスを展開させていただいています。

こちらがGroup Revenueの推移なんですけども見ておわかりのとおり、かなり順調に推移をしてる。で、今年は1.6兆円が見込まれてる形になってます。

ここから本題に入ります。本日は4つに分けてお話しさせていただこうかなと思ってます。

まずはそのファーストリテイリングはAWSをどうやって使ってるか、これKeynoteでも触れた内容なんですけども、Keynote出席されなかった方のためにも簡単に触れさせていただきます。

2つ目。ファーストリテイリングとしてAWSを長年使ってます。4年以上使ってるんですけども、その中で自分たちなりに見いだしてきたそのクラウド上で、システムをデザインするにはこうあるべきだというベストプラクティスだとかストラテジーをシェアさせていただこうと思ってます。

3つ目。ファーストリテイリングのユニークなところの1つなんですけども、Keynoteでもシェアさせていただいたように、かなりグローバルにリージョンを使わせていただいてます。なので、そこを具体的にどのように、ファーストリテイリングがAWSをグローバルに使ってるのか、特にネットワークの視点からお話しさせていただこうと思ってます。

最後4番目。荒にバトンタッチさせていただく形になるんですけども、エンタープライズを今後どのように変えていこうとしているのか、AWSを使ったストラテジーをお話しさせていただこうと思ってます。

「UTme!」などのユーザー向けアプリもAWSで運用

まずは1つ目なんですけども、ここはユニクロのアプリのポートフォリオなんですけども、ユニクロ以外にも基本的にはコンシューマ系のサービスもAWSに載ってます。特にユニクロで言うと、お客さん向けにこのようなたくさんのアプリを出してます。

最近だと「UTme!」っていうお客さんが自分でデザインを作って、それをそのTシャツにプリントアウトしたりだとか、バッグを作ったりだとか、そういうカスタマイズをできるようなサービスだとか。

本当に最近なんですけどユニクロの「CAMERAでPON！」。これはお子様が店舗でこのアプリを使って、実際にはARを使ってるんですけども、店内の中でキャラクターと一緒に遊べるサービスも展開したりしてます。

こちら普通にただのスクリーンショットになってるんですけども、アプリ以外にももちろんEコマースのサービスとかも弊社展開してるので、Eコマースのサービスとかも含めて基本的にはAWSに載ってます。

ここにはスクリーンショットとかはないですけども、コンシューマ向けのサービスだけではなくて、エンタープライズのシステム、例えば人事、会計のシステムとかももちろんAWS上に徐々に載っかってきてます。

こちらはトラフィックの大きさなんですけども、200億リクエストパーマンス、10万リクエストパーセック、これは要はピークのとき、これぐらい来てますよと。なのでご想像いただけると思うんですけど、かなり大規模なトラフィックを弊社ではさばいてます。

100以上のシステムがもうすでにAWS上に載っかっている形になってます。大小、いろいろ大きさはあるんですけども、基本的にはマイクロサービス的な考え方でやってるので、かなり細かい単位でそのシステムをそれぞれ分割して作ってます。

1300以上のインスタンスが動いている形になってて、これをだいたい3人ぐらいのインフラのメンバーがいるんですけども、3人ぐらいでさばいてる形になってます。

なのでご想像いただけると思うんですけど、3人で1300台のインスタンスを管理するのはものすごく大変なことなので、もちろんオートメーションだとか自動化を最大限やって、できるだけ効率よくクラウド上でインフラの管理をやってます。

クラウド上のシステムは独立性のあるデザインが大事

こちらがインスタンス数の推移なんですけども、現在1300くらいで今年中には2000台超そうと思ってます。意外なのが2011年。数は少ないですけども、意外と早いタイミングから実はファーストリテイリングでAWSを使い始めてます。なのでクラウドアーリーアダプターみたいな形で入れることができるんじゃないかなと思ってます。

ここからテクニカルな話になってくんですけども、ファーストリテイリングとして4年以上実はもうAWS使ってます。その中で特にエンタープライズ、特にオンプレでそのシステムをつくってきた方には特に響くと思うんですけども、オンプレでシステムを作るのとクラウド上でシステムを作るのは全然違います。

なのでその辺のクラウド上でどうあるべきかというベストプラクティスをシェアさせていただこうかなと思ってます。こちら黄色で書かれている7つ。7つのことをクラウド上では特に意識をしてそのシステムをデザインしなきゃいけないと僕らは考えてます。

1つずつブレイクダウンしていくんですけども、まずはインディペンデンシー、独立性ですね。要はクラウド上では、すべてのシステムはお互い独立した形で作られてデザインされるべきだと、先ほども触れましたけどマイクロサービス的な考え方です。

具体的に図を使って説明させていただくと、要はクラウド上にはたくさんのシステムが載っかってますよね。ファーストリテイリングであると、さっきお話させていただいたように1300以上のインスタンスで、100以上のシステムが動いてますと。

いままでエンタープライズはオンプレでシステムをやってきた人たちは、こういう形になってますと。要はシステム間でインスタンスを共有したりだとか、例えばここで言うと、システムCとシステムDはインスタンスを共有してますよね。あとは、例えばAとBみたいにデータベースを共有したりだとか、こういうアーキテクチャはいままでインタープライズの方は取ってきました。

これはなぜかというと、もちろんオンプレのときは、そもそもインフラの調達自体が時間もかかるわけだしコストもかかる。ただ、クラウド上ではそこの問題点は基本的に解決されているので、基本的にはそれぞれのシステムは、完全にインフラとして独立した形でデザインされるべきです。

で、要はお互いのシステム間でのインフラ的なディペンデンシーを最小化しましょうというのがコンセプトです。

とはいうものの、例えばAとBの間で共有しなきゃいけないデータだとかロジックだとかあると思うんですけども、そういうのはまた別のシステムとしてつくり上げて、そこを例えばAPI経由でインテグレーションする考え方でやるべきですよっていう話です。

あとこれのいいところは、そのシステムごとにそのセキュリティグループを設定することができます。つまり、システムごとにそのセキュリティーを担保することができます。

例えばシステムAを管理してるデベロッパーはシステムBには入れないし、逆にシステムBを管理しているベンダーはシステムAには入れない。こういう考え方もできるので、このインディペンデンシーはとても大事ですと。

フルマネージドのサービスを使ってメンテナビリティを高めよう

次がメンテナビリティ。皆さんご存じだと思うんですけど、要はAWSはEaaSのサービスだけじゃなくて、PaaSっていわれるプラットホームをフルマネージドで提供してくれてます。なのでこれをできるだけ使いましょうという話です。

ここにも書いてあるんですけど、要はいまのシステムってどんどん複雑になってます。メールも送らなきゃいけないし、キューも使わなきゃいけない。キャッシュもやらなきゃいけないし、もしかしたら検索もやなきゃいけないし、モバイルにプッシュを送らなきゃいけない。

いままでのエンタープライズはどうやってきたかっていうと、それをパッケージを入れたりだとか自分たちで開発をしてきたわけです。ただAWSって先ほどお話しさせていただいたようにPaaSという概念があって、それぞれを機能としてフルマネージドで完全に提供してくれてます。なのでそれをできるだけ使いましょうっていう話です。

そうするとどういうことが起こるかっていうと、要はこれすごい複雑なシステムに見えるんですけど、この丸で囲ってあるところは基本的にはフルマネージドのサービスです。

なので、僕らが自分たちでインフラを管理する必要がないです、面倒見る必要がないですと。本当にもう丸が付いてない、ここでいうとEC2のインスタンスが2カ所あるんですけども、そこだけ自分たちでちゃんとインフラとして面倒見なきゃいけない。

なので、要はフルマネージドのサービスをできるだけ使うことによってメンテナビリティを高めましょうっていう話です。

スケーラビリティは最初から担保されるべき

次がスケーラビリティです。ロードバランサーとオートスケールがあるんで、それを使ってクラウド上ではスケーラビリティは最初から担保されるべきですという考え方です。

エンタープライズの話でよくあるあるなんですけども、このシステムはスケーラビリティはいりません。本当に少ない人しかアクセスしないシステムなので、スケーラビリティってのは全然いらないです。

ただ結局何だかんだで時間が経ってくると、これ実は海外の人も使い始めます、他のブランドの人も使い始めます。結局なんだかんだでトラフィックがどんどん増えてきて、最終的にはちゃんとスケーラビリティが必要なシステムになっちゃいます。

なので何が言いたいかっていうと、要はシステムのリクアイアメンとなんて結局変わります。だったら最初からスケーラビリティがミニマムで担保できるように、最初からデザイン、クラウド上ではしておきましょうという話です。

こことあとロードバランサーが上にあって、あとはオートスケールレディインスタンスって僕ら呼んでるんですけど、要はオートスケールレディなインスタンスは状態を持ってない、状態を管理しないステートレスなインスタンスで、あとはそのインスタンスが起動したとき、要は再起動されたときに勝手に必要なサービスが起動する。それをASレディインスタンスの定義として僕ら呼んでるんですけども。

最初からそういうふうにインスタンスを作っておけば、ロードバランサーとオートスケールを組み合わせて、必要なときにスケールアウトすることは簡単にできますよね。ユニクロのアプリとかもそうなんですけど、LINEのプッシュだとかユニクロのモバイルのアプリのプッシュかが送られた直後はものすごくスパイクします。

なので実際にプッシュが送られる直前に、例えば10台から30台に増やして、それが落ち着いたらまた30台から10台に戻してみたいな形で、要はスケーラビリティを最初から担保していることによって恩恵を受けられます。

最初からアベイラビリティを担保するようにデザイン

次がアベイラビリティです。アベイラビリティは、マルチアベイラビリティゾーンとかリージョンとか聞いたことあると思うんですけど、要はクラウド上ではこのアベイラビリティの担保が簡単なので、最初からアベイラビリティはちゃんと担保しておきましょうという話です。

先ほどのスケーラビリティのときと同じなんですけど、エンタープライズのあるあるで、このシステムは落ちても大丈夫ですと。よくあります。結局何だかんだ言って、例えば役員が使い始めます、落とさないでくださいと。

あとはもちろんさっき言ったみたいにグローバルで使い始めるんで、できるだけ落としたくないです。結局要はリクワイヤメントなんてどんどん変わってきますと。だから最初から、もうこれはアベイラビリティはいらないシステムだって想定をしてしまわずに、最初からアベイラビリティを担保した形でシステム、デザインしておきましょうよという話です。

これはアベイラビリティの、マルチアベイラビリティゾーンを使ったタイプなんですけども、要は最初からミニマムでアベイラビリティが担保できるように最初から作っておくことがものすごく大事だし、エンタープライズのときは要は、インスタンス1つの中でどうやってアベイラビリティを最大化するかを考えてました。

でもクラウド上ではそのインスタンス1つでどうアベイラビリティを担保するかではなくて、システム全体でどうアベイラビリティを担保するかっていう考え方でやらなきゃいけないです。それがそのアベイラビリティゾーンだとかリージョンという考え方につながります。

システムが素早く復旧するように最初から作っておく

次はリカバラビリティ。これは要は何かシステム的なトラブルがあったときに、できるだけ早くシステム的にリカバリできるようにしておきましょう、最初から作っておきましょうという考え方です。

当たり前なんですけど、インスタンスが落ちることだとかインスタンスに何か障害が起こることってよくあります。いままでどうやってやってたかっていうと、弊社の場合だと、例えばSlackとかインテグレーションされてるので通知が来ます。何かおかしいですと。

いままでって、ベンダーだとかモニタリングの会社だとかが、何かその通知を受け取ったときにトラブルシュートしに行きました。例えばどこのプロセスが悪いのか、どこのアプリが悪いのか、どこのロジックが悪いのか。例えば、Node.jsが悪いのかNginxが悪いのか、Rubyとか使ってたらUnicornが悪いのか、要は時間をかけてトラブルシュートしようとしたんですね。

ただもうそういうのはクラウド上ではやめましょうよ。トラブルシュートはあとでやればよくて。このオートスケールレディなインスタンスを最初から作っておけば、要は何かあったとき、とにかくインスタンスをリスタートだけすれば大丈夫です。リスタートだけしたら要はこのオートスケールレディのインスタンスは状態を管理してないので、データの外にちゃんとあります。

サービス自体も自動的に立ち上がるように作られてるので、基本的にはすぐサービスイン可能です。なので、まずはとにかくインスタンスのリスタートだけしてあげたら勝手にそのサービスのシステムが復旧するように最初から作っておけばいいじゃん。トラブルシュートは後で勝手にやりましょうという話です。

システムを簡単にコピーできるように最初から作っておく

次がレプリカビリティですね。クラウド上ではシステムを簡単にコピーしてクローンできるように最初から作っておきましょう。もちろんプロダクションの環境は必要です。

エンタープライズの時代にはインフラの調達がいろいろ大変だし、コストもかかるので、制限された環境しか作れませんでした。ただ、クラウド上ではもちろん、要はその辺の問題は解消されてるので、そのプロジェクトが進んでいくといろいろな環境が必要です。

ステージングが必要。インテグレーションの環境が必要。パフォーマンステストをしたいからストレステストの環境をくれ。もしかしたら開発がパラレルに3つ、4つ走るかもしれない。

だったらもう最初からAWSのクラウドフォーメーションっていうサービスがあるんですけども、要はテンプレとかにしておいて必要なときにいつでもそのシステムがクローン、簡単にコピーできるように最初から作っておきましょうっていう話です。

クラウド上ではIPベースをやめて、名前ベースに

次がポータビリティですね。いままでエンタープライズってよくありがちなのが、基本的にIPベースでいろいろ管理されてました。だからクラウド上ではもうIPベースはやめて、全部名前ベースに変えていきましょうっていう話です。

この図を見てもわかると思うんですけど、これそんなに複雑なシステムじゃないと思う一般的なシステムなんですけども、要はシステムというのはいろいろなエンドポイントをつなぎ合わせて作られてますと。

いままでは要はそれを全部それぞれがIPアドレスが振られてました。IPアドレスで基本的にはインテグレーションされていたので、例えばデータベースが他のサービスに変わるとか、例えばここで言うとRedisっていうキャッシュのメモリキャッシュのサービスを使ってるんですけども、それを例えば他のMemcachedに変えますとかいろいろ変更があったときに、そのIPアドレスを参照しているところすべて書き換えに行かなきゃいけない。要はポータビリティが全然なかったです。

ただクラウド上ではちゃんとその自分たちが持ってるホストネームで、それぞれのエンドポイントをちゃんと管理しておきましょう。そうすると何が起こるかっていうと、例えばデータベースのところはオンプレに戻るかもしれない。もしかしたらデータベースのところが他のクラウドサービスに移るかもしれない。

ただそうなったときも自分たちがちゃんと管理しているホストネームでお互い連携されていたら、例えばそういう引っ越しがあってマイグレーションが必要になった時とかも、DNSの切り替えだけやれば簡単にシステムのマイグレーションができますよね。

なのでクラウド上では最初から名前ベースを使っていくことによってポータビリティを最大化しましょうという話です。これはブルーグリーンデプロイメントって皆さん聞いたことある話だと思うんですけども。要は、ホストネームベースで最初からこういうふうに管理しておけば、そういういままでのデプロイメントのやり方ではなくて、先ほど言ったクラウドフォーメーションみたいな形で、新しい環境を完全にコピーしてしまって新しいアプリケーションを載っけます。

それがレディになったらそっちにトラフィックをDNSの切り替えだけでそっちにトラフィックを流して古い環境を捨ててしまう。そういう考え方も基本的には簡単にできますよねというお話です。

できるだけたくさんデータをクラウド上に集めておく

最後なんですけども、これはビジビリティ。要はできるだけたくさんデータをクラウド上では集めておきましょうっていう話です。

何が言いたいかというと、この図を見てもわかるように、いまのクラウド上のシステムはたくさんのフルマネージドのサービスで構成されてます。それをお互いインテグレーションした形でそのシステムとして動かしてます。

ただ、要はエンタープライズのときと違うのは、エンタープライズのときは自分たちでそのデータセンターを管理してました。だからビジビリティがものすごく高いわけですし、何かあったときに要は自分たちのコントロール下にすべてインフラがありました。

ただクラウド上ではフルマネージドのサービスとかを使ってると何が起こったか。例えば障害とかが起きたときに何が起こってるのか、どこが悪いのかを判断するのがとても大変です。

なので、ちゃんとこのクラウドウォッチとかを使って、必要な情報、取れる情報はできるだけ最初から集めておきましょう。クラウド上では何かあったときにちゃんとそのトラブルシュートができてアクションが起こせるように最初からやっときましょうっていう話です。

いままで7つ、ベストプラクティスという形で紹介させていただいてきたんですけども、要は何が言いたいかっていうと、いままでそのエンタープライズオンプレミスベースで考えてたデザインされてたベストプラクティスだとかシステムのデザインは、基本的にはそのままクラウド上では通用しないです。

なので、よくあるんですけどいまオンプレで動いてるシステムをクラウド上に持ってきます。ただそのまま持ってきます。よくあります。ただ、それじゃ意味がないんですよ。なので、クラウド上ではちゃんとクラウド上で、その最適なベストプラクティスがあります。

だから、ただオンプレで動いているのをただクラウド上に持ってくるんじゃなくて、ちゃんとこういうクラウドにフレンドリーなアーキテクチャだとかデザインもちゃんと考えて、ちゃんとクラウド上に持っていきましょうと言いたいです。

オレゴンとサンパウロ以外のリージョンはすべて使っている

3つ目なんですけども、ここからはファーストリテイリングのユニークな部分の1つとして、グローバルなリージョンを使っていることがあります。

具体的にそこがどういうふうに、例えばネットワークとして構成されているのかだとかテクニカルなお話をさせていただこうと思います。これKeynoteで玉置さんのほうからもシェアありましたけれども、ファーストリテイリング自体はグローバルにビジネスを展開させていただいているので、コンシューマもそうだし、実際のお客さんもそうだし、従業員だとかストアのスタッフ含めてグローバルにいらっしゃいます。

なので現在現段階でも、オレゴンとサンパウロ以外のリージョンは基本的に全部使ってるような形になってます。それぞれのリージョンの中がどのようにネットワークとして構成されているかっていうと、この図にあるように実は4つ、VPCとして分かれてますと。

プロダクションステージングデべロップメントは基本的にはサービスのためのVPCです。要は本番環境、ステージング環境、開発環境みたいな形で、完全に環境によって完全にそのVPCごとに分けてます。

要はプロダクションには、それがB2Cのコンシューマ向けのサービスであろうが、人事、会計のようなエンタープライズのシステムだろうが、共存している形になってます。お互いのVPC間はそもそも環境として完全に独立しているので、お互い行き来できないとっていう構成になってます。ただ逆にマネジメントはどこにでもアクセスできます。

なので、例えば監視系モニタリング系のシステムだとか、OpenVPNだとかLDAPみたいなマネジメントに必要なもの、どこにでもアクセスしなきゃいけないものが、要はここにホスティングされるみたいな、それ専用の特別なVPCとしてつくられてます。

ダイレクトコネクトに関してなんですけど、2つ使ってます。プロダクションとマネジメントのために太めの10ギガを使ってて、逆にそのステージングとかデベロップメント用に細めの1ギガを2本引いてます。

弊社の場合もオンプレのほうにExadataがあるので、基本的にはそのクラウドとオンプレのシステム的なコネクションのためだけにダイレクトコネクトを使ってます。なので、例えば従業員がAWSにアクセスするとかにはダイレクトコネクトは一切使ってません。

逆にこのような形で他のお客さんと同じなんですけども、インターネット経由、インターネットオーバーで専用線とかを一切使わず、インターネットオーバーを使って普通に人事、会計のシステムだとか、一般のお客さんであったらユニクロのサービスだとかを使う形になってます。

逆にデベロッパーはオープンVPNを使って1回そのマネジメントに入ってきて、そこからマネジメントはどこにでもリーチャブルなので、必要なインスタンスにそこからつなぎに行く形になってます。

各リージョンのVPCがお互いつながっている状態に

いまお話ししたのが要は1つのリージョンの話なので、それがすべてのリージョンにつまっているイメージです。で、ダイレクトコネクトに関しては、東京とバージニア、いまはその2ヶ所つながっている状態になってます。

そもそもじゃあそのクロスリージョンでどういうふうにお互いが構成されてるのかなんですけども、僕らはクロスリージョンでピアリングをやってます。

要はどういうことかっていうと、プロダクションのVPCはどのリージョンにもあります。東京のリージョンにもプロダクションあるし、アイルランドにもあるし、シドニーにもあります。それぞれのリージョンのプロダクションっていうVPCがお互いつながっている形になってます。

要はそのシステムが、シドニーリージョンにあろうが、東京リージョンにあろうが、アイルランドリージョンにあろうが、基本的には意識することなく行き来できるし、つながるような状態。基本的にはそのリージョンを意識しないでいいような形をコンセプトのもと、こういう構成にしてます。

なのでステージングももちろんすべてのリージョンにあるんですけども、ステージング同士もお互いがつながり合ってるみたいな形。ここにも書いてありますけど、メッシュのトポロジーを使っているので、アベイラビリティが担保できます。

要はどこかが切れても、他の行き方でお互いリーチャブルだという形で、アベイラビリティも要はメッシュのトポロジーを使うことによって担保してます。ここは結構ソリューションどういうの使ってるかって話になっちゃうんですけど、そのVPCピアリングがあります。ただ、そのVPCピアリングは各リージョンごとに閉じた話で、リージョンをまたいでは使えません。

なので、弊社の場合、そのVyOSを使って、そのクロスリージョン、リージョン間でのコネクティビティを担保してます。ただご想像できると思うんですけど、要は1個の何かコンフイギュレーションを変えなきゃいけない。

例えば東京リージョンのVPCの構成が変わりましたとか、新しいリージョンが追加されましたとか言ったとき、お互いがお互いつなぎ合ってるので、すべてのVyOSのコンフィギュレーションを変えにいかなきゃいけないですと。それは考えただけでもものすごく大変ですと。

だから弊社の場合、何をやってるかというと、サーフっていうオーケストレーションツールがあります。要はサーフは、変更を自動的に検知して勝手にコンフィギュレーションアップデートしてくれる、お互いがお互いを監視しているような形になっているので、要は自分たちでマニュアルですべてのところにアップデートをかけにいかなくても大丈夫なようになってます。

実際のお客さんからのアクセスもこのような形で例えばUSにいるユーザーさん、例えばそれがコンシューマだろうと、それが従業員だろうと、ストアスタッフだろうと、基本的にはインターネットオーバーでエッジに入ってから、そこからそこがリバースプロキシみたいな形になってて、そこに近いリージョンのプロダクションにつながったりだとか。

そのシステムがもしかしたら東京にしかないかもしれないので、そういうときは東京につなぎにいったりだとか、そのユーザーさんがどこにいるかによってそのつなぎ方をエッジがコントロールしているような形になってます。

デベロッパーの場合は先ほどお話ししたように、オープンVPNなんですけども、USのデベロッパーだとか、アジアのデベロッパーだとか、オーストラリアのデベロッパーだとか、基本的には自分たちがいるところに一番近いリージョンのマネジメントにOpenVPNのエンドポイントがあるので、そこに繋ぎにいきます。そこから必要なところのインスタンスに入りにいく形になってます。

いままでグローバルネットワークデザインというところでお話しさせていただいたので、これから荒にバトンタッチしてエンタープライズの話をさせていただきます。

エンタープライズ部門ではAWSをどのように活用しているか

荒：はい、荒です。ここまでお話をさせていただいたコンシューマの話と比べて、エンタープライズの基幹系のところはまさにこれから始めたところなんですけれども。

会社としてクラウドネイティブなアーキテクチャを作っていって、ただクラウドを使うだけじゃなくてさらにそれ以外のエンタープライズの部分に関しても一気に変えていって、アーキテクチャもセキュリティも考え方を変えて加速していくところをお話しさせていただきたいと思ってます。

まず始まりは、一昨年のre:Inventにエンタープライズを担当しているエンジニアが参加させていただきまして。ちょうどその昨年の3月、ちょうどいまホスティングをさせていただいている会社の契約の満了の1年前といったタイミングで、今後新しい基盤ってどうしてくのかって考えたときに、この前話を聞いたAWSってどうなんだろうと思いついたところが始まりです。

そこから半年ぐらいかけて、社内でまずは環境を実際に作ってみて、社内の環境とAWSとの間でDirect Connectも実際に引きがら、どういうふうにパフォーマンスが担保できるのか、どういうアーキテクチャを採用したらクラウドネイティブになるのかを、先ほどの福田の知見も借りながら考えていきました。

そのあと11月のタイミングで、部長、CIOといったところへの報告、承認をもらったあと、CEO、経営陣に対する説明も行いました。反応というのは、基本的にもう新しいテクノロジーをどんどん使っていきなさいと。セキュリティーなんかエンタープライズの企業は気にされると思うんですけど、餅は餅屋で一番強いところに頼むのがいいに決まってると。

「まだやってなかったのか。早くやりなさい」という経営陣の言葉で、「そういった形で3、4年使ったシステムはもうビジネスの進化についていかないんだから、システムもどんどん最高の技術を使って新しいもの入れていきなさい」っていう言葉に後押しされて、エンタープライズのエリアでのAWSの活用をまさにスタートしたところです。

いまの段階では先ほどの福田の話にもありましたとおり、Exadataがありまして、これはすぐにはAWSに移行できませんので、まずは持っていけるところ、WebサーバとかAPサーバとか共通系の運用管理の仕組みを持っていくところを最初のスコープにしてます。

そこでまずはシンプルな、例えばコスト削減とか運用の自動化とか、よく聞くような利益を享受したいということで、まずはできるところを上げていくのをいまやってます。細かいところは先ほど福田の説明もありましたので割愛しますが、こういう移行作業をやって今年の8月の段階で人事、会計のシステムは完全AWS移行になります。

そのあとも順次、基幹系のシステムを持ってきますが、同時に先ほど申し上げたとおり、新しくシステム導入をするような案件については、もう初めからAWSを採用してクラウドベースでやっていくことで、もうアーキテクチャも含めてクラウドネイティブなものを採用していくところを並行してやっております。

そもそもエンタープライズの企業、クラウド使うときの目的って、クラウドを使うのが目的というよりもクラウド使うことによって得られるアジリティーだったりとか、特にそのUXの高いコンシューマ系のモノ作りの仕方とかをエンタープライズのエリアに持っていくところが目的で、その手段の1つがクラウドだと思ってます。

ここに書いてある上の2つはクラウドを使うときの流儀みたいなもので、エンタープライズをやってる人からすると最初違和感があるだろうなと思うのが、壊れる前提で落ちる前提でアーキテクチャ作りましょうというところだと思うんですね。

データそのものを守らなければいけない時代に

それたぶんここにいらっしゃる皆さんわかってらっしゃるかもしれないですけど、そこに加えて、やっぱりさっき福田もあったとおり要件って変わるよねと。だから要件定義を長々とやってようやくシステム作り出すよりも、細かい小さなクイックインを積み重ねながら、だんだんこういう意識をみんなで合わせていくアジャイルな作り方を、できる限りエンタープライズのエリアにも持っていきたいと思ってます。

ただ、考え方変えるだけじゃ駄目で、そもそもクラウドを使うときって、例えば企業のネットワークに関しても、そもそも例えばクラウドを使っていくSasSを使っていくときに、もともと多くの企業が持ってたWANを通した通信ってどんどん少なくなっていって、インターネットベースになっていくと思うんですね。

そうしたら、企業の環境、ネットワーク環境を大きくドラスティックにインターネットベースに変えていくべきだと。例えば、今だったら物理的な危機でネットワーク構成しているところを、バーチャルアプライアンス使ってAWSに載せて全部クラウドベースでできるよねっていう。

そうしたらネットワークの変更とか、例えば新しいエリアに出店するときもスピーディーに対応できるところも、今後どんどんチャレンジしていきたいなと思ってます。ネットワークもインターネットベースになってきたら、今度はセキュリティの考え方も変わるかなと。これ私の考えをお伝えしたいんですけど。

もともとの企業のセキュリティの考え方は、閉域網をきっちり守って、その中にデータを閉じ込めてそこから出さない形でセキュリティを担保する。だからパソコンの持ち出しのルールとかをやるんだと思うんですけど。

そもそもこれからの時代データは社内にないですよね。全部社外に出ちゃってる中でいままでのセキュリティの考え方じゃ全然ついていけなくて、どうするかっていったら、データを守らなきゃいけないと思うんですね。データそのものを守る。

そのための技術は、従来の暗号化もあるしライトコントロールみたいなものもあって、そういったものを使って外に出ていったデータをきちんと守ってくってのもあるんですけど。また昔の話に戻ると、WANでやってるとそこが守られてる前提でログを取れば良かったですよね。ログを取って何かあったときはログを見て追いかける考え方から、もうインターネット上に出ちゃってるものが危機にさらされたらすぐに何とかしないとまずいので。

そうするともうリアルタイムでモニタリングして、まずかったらすぐアクセス遮断するリアルタイムな監視、アクションが求められる。こういった形の単にEC2、S3使って、エンタープライズのシステムをクラウド持っていくだけじゃなくて、そもそもエンタープライズの仕組み全体の考え方を変えるところも踏み込んでやっていきたいと思ってます。

OSSを使った仕組み作りにチャレンジ

ファーストリテイリング、ITとして今後どうしていくかに軸足を置いてお話をしますと、今後2020年にファーストリテイリンググループとして売上5兆円を目指していまやっております。

そこに資するITとしていまお話しした通り、もともとあるエンタープライズの壁を壊して、どんどんコンシューマ向けであったりWebベースのOSSを使ったようなアーキテクチャを取り入れて、どんどんアジャイルな仕事の進め方を、文化も含めて導入していきたいと思ってます。

当社の中ではそういったそのエンジニアがすぐに社内で環境に適応できるように、OSSベースというかWebアプリケーションを開発して、デベロッパーの方に親和性あるような例えばSlackとかGitHubとかの開発環境を整えて、エンタープライズであってもそういったところで仕事ができるように、どんどんOSSを使って仕組みを作っていくチャレンジをしていきたいと思っています。

こういったことをするのにAWSが必要不可欠でして、これまでもこれからもAWSを活用した基幹系、コンシューマ系、両方の仕組み作っていきたいと思ってるんですけど。もう1つ大事なことが人です。ここでやはりエンタープライズにしてもコンシューマにしても、いまお話ししたようなところでコンシューマは結構やってます。

エンタープライズはこれからですけど、もう全体を変えていって大きくドラスティックに変化していく仕事の仕方をしていこうと思っていて、ここに対して一緒にやりたいという方をぜひ募集したいと思います。

ファーストリテイリングのイメージを変えたい

福田：補足させていただくんですけども、自分も実はWebのバックグラウンドがあって、前職はWebの会社にいました。ファーストリテイリングはそもそも皆さん、外から見たときはあんまりテクニカルにもそんなトレンドを得てないしアドバンスじゃないし、特にWebのエンジニアからしたら、そもそもファーストリテイリングは、応募する対象にもならないみたいな形があると思います。

ただ、荒のほうからもお話しさせていただいたように、いま本当にオープンソースを積極的に、それはコンシューマ系もそうだし、そうじゃなくてエンタープライズの仕組みも含めて積極的に利用しているし。

あとは内製化どんどん進めているので、いままでベンダー頼みだったところをどんどん自分たちで開発をしていって、要はクイックにビジネスに影響を与えられるシステムをどんどん作ろうとしてます。なので、この中にWebエンジニアの方はどれぐらいいらっしゃるのかわからないですけど、イメージを実は変えていただきたくて。

ファーストリテイリングでもWebエンジニアの方々が活躍できる場はものすごくたくさんあります。なので、もし興味があったらぜひ一緒に働きたいと思っているので応募をお願いします。

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