ローソンがAWSを使う上で苦労したこと、工夫したこと
進藤広輔氏：皆さんこんにちは。ローソンの進藤と申します。本日は、「ローソンがAWSを使うまでの軌跡～打ち破れ、現行踏襲～」ということで、いろいろとAWSなど新しいものを使う上で、いろいろ苦労してきた点、あるいは工夫してきた点を皆さまにご紹介して、いまAWSを活用しようとしている情報システム部の方々や、いまいちまだAWSを理解しきれていないSIerさん、ベンダーさんの何かのヒントになればなと思って、今日このお時間をいただきました。よろしくお願いいたします。
本日のアジェンダですけれども、こちらの5点で進めさせていただきます。まず最初に簡単に会社紹介を進めさせていただきたいと思います。皆さまご存知のとおり株式会社ローソン、コンビニエンスストアを全国に展開している会社でございまして、全国に約1万3000店のお店を展開している企業になります。
今回、注目していただきたいのは、創立、設立が1975年なんですけれども、実はローソン来月で40周年を迎える、今年で40周年を迎えていまして、これからいろいろなキャンペーンですとか、いろいろなフェアを実施して、開催していきます。
お店の方でも、新しい商品を皆さまにお届けできるように準備を進めていますので、ぜひお店のほうに足を運んでいただいて、商品を手に取っていただいて、ぜひローソンをお楽しみいただければと思っておりますので、最寄りのローソン、帰宅途中のローソン、出社途中のローソンにぜひお寄りいただければなと思いますのでよろしくお願いいたします。
私の自己紹介を簡単にさせてきていただきたいと思います。あらためまして、進藤広輔と申します。よろしくお願いいたします。いまAWSをメインで担当させていただいておりますが、ベースのスキルセットとしましてはネットワークとセキュリティであります。
いまはAWSをやっていますが、いままでは前職はベンダーサイドにいまして、転職して約2年目ぐらいになっております。いま私はAWSの関連するプロジェクトの統括と推進ということで、全案件をプロジェクトマネージメントする形で進めさせていただいております。
余談ですが、ピークでは、13案件マルチでPMしろという状態ですね。これはっきり言ってありえないと思っていたんですけども、そんな中でAmazonから今日講演してくれという話で、また鬼だなと思ってですね。困ったこともあったんですけど、なんとか説明させていただいております。
このくらいにしておきまして、本題に入りたいと思いますけれども、まずローソンとAWSということで、ローソンがどのようにAWSを見てきたのか、活用しようとしてきたのかを簡単にご紹介したいと思います。
AWSを検討するときは加点方式がおすすめ
ローソンデータベースのこれまでですけれども、ローソンがAWSの存在を知って検討を始めたのが2013年の夏ぐらいからですね。そこから2015年の本日に至るまでいろいろな検討を進めてきまして、いま業務的なシステムもいくつか載せて実際にAWSを利用してシステムを展開しているところです。
情報収集いろいろ皆さんもされると思うんですけれども、いくつかポイントがあると思います。私がやってきた中でポイントと感じていますのは、新しいものとかいままでと違うものをやるということ、それ自体が基本的には皆さんの心理の中でマイナスに働く部分が多いと思うんですよね。
その中で情報収集をする検討するときに、マイナスの減点主義、減点方式で評価をしていってしまうと、使う理由ってなかなか見つからないと思うんですよね。なので、できる限り情報収集する、検討する場合は加点方式で、AWSだったら何ができるようになるのか、いままでと何が違った形でメリットを享受できるのかにポイントを当てて情報収集、検討を進められるとAWSの活用が見えてくるんじゃないかと思います。
2014年には実際に検討から試すということでトライアルで使い始めたんですけれども、ここも一番重要なポイントがあるんじゃないかなと思います。いろいろなセッションでも、すでに言われていることかもしれませんが、あまり検討のための検討に時間をかけても意味がないと感じています。
やはりAWSは、1つのメリットは使いやすさ、利用のしやすさがありますので、まずは試す。自分で試してみて自分で感じた肌感覚を信じて使えるか使えないかを判断していく。そういった観点が重要なのかなと思っています。
実際に試すときには、標準的なWebAPDBサーバの構成ですと、言ってしまうと1ヶ月の利用料ぐらいでしたら、小口決済で済むぐらいを超えないので、ぜひまずは使ってみて、どんなものなのかを確かめられることをお勧めしたいなと思っています。
短期間の実験がしやすくなった
次、続きまして、ローソンがどのようにAWSを使おうとしているのか、推移ですね、数量的に表してみましたけれども、2013年の検討当初はトライアルの試行を始めまして、当初は2案件程度だったんですけども、2015年現在、いまもう少し増えちゃっていますけれども、15案件から16、17案件ぐらいの実際のシステムの利用と検討が進められています。
検討と利用の内訳に関しましても、店舗系とか、ローソンのお店の仕組みを使うためのAWS、あるいはその本部系とかEC系、こちらのほうでの検討あるいは利用も進んでおりますし、実験ですとか基盤といった部分での検討構築も進んでいます。
一番特徴的なのはこの実験系と書かれているところですけれども、いままでのオンプレミスの時代ですと、とりあえずお店でこういうことやってみたい、こういうのに取り組んで2、3週間で試してみたい、という話があったときに何が一番ネックになったかというとやっぱりハードウェアの調達だったと思うんですよね。
それがAWSを使うことによって、言ってしまうと明日立ち上がる、明日試せる、アプリケーションが載ればというところもありますけれども。とりあえず3ヶ月やってみて何かしらの数値を得てみたいといった実験では、非常に使い勝手のいい仕組みで、こういったところはどんどん利用が進んでいる状況でございます。
続いて、実際どのくらいローソンはAWSを使っているのかをもう定量的に表してみようかなと思って、こちらのほうにまとめてきましたけれども、インスタンス数でいうと200から500というぐらい、EC2でいうとそれぐらい使っていますけれども、一番のポイントは数ではなくて、ローソンは基本的にはAWSの利用方針としてAWSのメリットを最大限活用しようと、オンプレとは決定的に違う形で使っていこうと考えていますので、できる限りスケールアウト、スケールインをさせる仕組みで使うように心がけています。
また、DBサーバ、RDSなんかも使っておりますけれども、基本的にはフルマネージドによる使いづらさに目を向けるのではなく、フルマネージドであることのメリットに目を向けて、徹底的にRDSならRDSを使いこなしていく形で利用を進めているところです。
サービスを組み合わせて使うときにトラップがある
続きまして利用しているサービスですけれども、ここに記載されているようなものはよく一般的に使われているものだと思いますけれども、広く一般的にいわれているものはローソンでも普通に利用させていただいております。
あまりトリッキーな使い方とかはしないで標準的に使い込んでいこうと、まずはベーシックに使っていこうと考えております。こういったAWSのサービスにOSSとかを取り込みながら、あるいはインフラのデプロイ部分を自動化しながらとか、そういったものを合わせて取り組んでいるところです。
あと1つですね、ぜひこの場でお伝えしたいのは、一つひとつのサービスありますけれども、利用するのは非常に簡単だと思うんですけども、このサービスを組み合わせて使おうと思うと意外にハマるポイントが多いかと思います。
私たちもいろいろと使ってみて、初めてはまるトラップみたいな、トラップにはまったとかもありましたけれども、なかなか自力で解決できない。そこがある意味もうマネージドサービスの苦しい部分があると思っていますけれども、そんなところにいち早く、いままでのベンダーの対応とは考えられないくらいのスピードで対応してくれたのが、画面の左はじのほうに、向かって右手にありますエンタープライズサポートとプロフェッショナルサービス。
こういったサービスを活用することによって、我々では解決できなかった問題や課題、あるいは未知の問題に対処することができるようになったのは、ここで宣伝になっちゃうかもしれませんけども、ぜひプロフェッショナルサービス、エンタープライズサポートの活用も考えてみてはいかがでしょうかと思っております。
いま実際にローソンの仕組みがどうなっているかを簡単に絵であらわしてきました。システム分野は都合ありまして表示することができませんけれども、このような形でいまローソンはAWSを使っています。
業務系のシステムが約7つほどですね。いまもう1個増えていますけれども動いている状況で、下のほうに表しているのが基盤系の仕組みになりますけれども、共通的に使う共通基盤といわれているものが稼働している状況でございます。
各データセンターとDirect ConnectでAWSがつながっているのも1つの特徴かもしれません。続きまして、ここまでローソンはAWSを使ってきたんですけども、どのようにアプローチをしてきて利用にまで至っているのかを簡単にご紹介したいと思います。
AWSの導入に開発ベンダーが難色を示した
2013年の夏に検討を始めた当初、ローソンがクラウドファーストだと、AWSを使ってみようと思ったときに、そのとき我々ローソンの対面にいた開発アプリケーションベンダーさん、あるいはその他のベンダーさんも含めてAWSいきますよと言ったときに、ポジティブな回答を返してきてくれた対応してくれたベンダーさんって意外に実は少なかった、というのがあります。
知らないぐらいだったらまだいいんですけど、どこでどういう情報を得てそういう話になったのかよくわからないんですが、クラウドは厳しいですよとか、AWSでは動かないですよといったようなお話もあって。
このままでは検討すらままならないので、どうしようかと考えて、やっぱりそうなるんだったら自らが興味を持ってやるしかないと、先ほどの繰り返しにもなるかもしれませんが、どうやったら使えるのか、どこになら使うことができるのかを徹底的に考えました。聞くと試すというサイクルをグルグル回したが検討の最初のアプローチの仕方になります。
この時は、ローソンのいままでのお付き合いのなかったパートナーの方を2名、私のサポート役でお願いしまして、初めてコンビを組んで3名の体制で検討を開始しました。3名の体制で、考える・聞く・試すというサイクルを回したのが検討の最初のアプローチになります。
いろいろAWSを使うとなると、「簡単に使えるよ」「ボタン1発でサーバを起動できますよ」と、よく言われると思うんですけども、やっぱり本格的に導入するにあたっては考えるポイントがあります。
そもそもAWSというのがエンタープライズのサービスレベルを満たすものなのか、信頼性とか性能とか、いわゆるそのノックアウトの条件がAWSさんはないのか、あるのかはざっくりとまず最初に調査しました。
それからもう1つは、やっぱりAWSを使うといっても、オンプレミスの仕組みはできる限り流用しなければいけない部分もあるかと思いますので、いままでの仕組みをどこまで流用可能なのかも時間をかけて検討いたしました。
あとは自分の勉強という意味も含めて、周りにだんだんAWSを使うことを周知していかなければいけませんので、オンプレミスの今までの世界とは何が違うのかを、Amazonのご協力を得ながら勉強して調べていきました。
AWSを得意とするベンダーに声を掛けたほうがいい
いろいろと調査を進めるときには、いままでのお付き合いされているベンダーさんやコンサルさんといろいろ会話するやり方もあると思いますけれども、もう1つ別のやり方として、いままでお付き合いのなかったAWSを専業にしているベンダーさんやその他AWSを得意としているベンダーさんにお声掛けをすることによって、自分たちが意図するAWSの使い方、あるいはAWSの利用方針を検討深めることができるケースがありました。
逆に言うと、あまり意図しない方向に進められるケースがいままでの流れだとあったのではないかなと感じております。ローソンはAWSの本格利用を進めようと舵を切ったところで、何に問題があったかというと、ローソンのアプリケーション開発の体制がマルチベンダー体制ということで、複数のベンダーさんが1個の仕組みを作る、あるいは複数の仕組みを作るということで対応していきました。
そうしますと何が問題かというと、やはりこのシステムの品質を一定に保つのがなかなか難しいということもあって、やっぱりある程度の規模のシステムを一定の品質を保って安定的な運用までつなげるためには、やっぱり共有された一種の想いですとか、哲学みたいなものが必要なのかなと感じました。
そして、その哲学だけでは当然何も回りませんので、その哲学を反映したルールを整えていって、そのルールをきちっとコントロールするガバナンスというか、統制していく動きが必要ではないかということで、ローソンとしてはAWSの本格利用に向けた取り組みの第1弾として、共通基盤の実装と、それからAWSを利用する上でのポリシーやガイドラインの確立、標準化の推進をを第一に掲げて対応してきました。
まず認証などの共通基盤を構築した
ここからは共通基盤は一体どういったものなのかとか、ポリシー・ガイドラインとはどういったものなのか、簡単にご紹介していきたいと思います。
共通基盤っていったい何なのかっていうと、よく他のエンタープライズ系の方々でも使われてるケースもあるかと思いますので、特に目新しいものはないのかもしれませんが、全システム横断で必要な基本的機能の提供ですね。
例えば認証系ですね。LDAPだとかActive Directoryだとか、あるいは監視とか、jobとか、システムに特化せずに幅広く汎用的に使えるようなものをきちっと備えましょうと。システムとの個別最適を避けて機能重複も防ぐといった目的で共通基盤を作ろうという話になりました。
共通基盤の特徴は、ここにも書かれているとおり、先ほど申し上げたとおり、システムに左右されない機能の集合と、あとはAWS上に構築されるものは基本的には全部使う。絶対ここを活用するんだということで、構築を進めてきました。
実装されている機能が、こちらにいま表示されているものになりますけど、先ほど申し上げたとおり、監視ですとかjobの仕組みですね。それからセキュリティ対策、それからログの集約ですとか、ログの機能ですね。
それから認証系とか構成管理の仕組みなどを共通基盤として実装して、AWS上で構築されるシステムはすべてそこを利用する統制です。ルールとコントロールを実施していきます。そういったものを実装したのを共通基盤と我々は呼んでいます。
ベンダーに依存しないためにポリシーとガイドラインが必要
続きましてポリシーとガイドラインです。ポリシーとガイドラインを作成した目的は、やはり作りやすさが表に出る仕組みですので、属人化あるいは属ベンダー化を避けなければいけないということで、ローソンのAWSでシステムを作るのであれば、属人化、属ベンダー化を防ぐためにこういうポリシーに従いなさい、こういうガイドラインを一応参照しなさいといった目的で、ポリシー・ガイドラインを整備しました。
もう1つは目的としましては、もうベンダーに依存しないシステム開発、システム構築をローソンの手で、ローソンが主導権を握って、これからは推進していくんだということで、その前段階の準備として、ポリシーやガイドラインをきちっと用意した形になります。ポリシーとガイドラインとは何かというと、ルールブックそれからノウハウ集のようなものになります。
今回はその具体的なポリシーとガイドラインを示したものは、目次レベルで今回持ってきていないのですが、どういったことをルール化しているかというと、AWSの利用する方法、方針を示したもの、それからベンダーさんとかSIerさんとシステム開発をやっていきますので、「インフラとしてはここまでやりますよ」とか、「アプリケーション開発はここまでやりますよ」といった、ベンダーさんとの線引き、役割分担の方針、基準ですね。
それからAWSを利用する上での設計方針、例えば、AWSの機能は、最大限マネージドサービスを活用するとか、オートスケールするようなAWSの特徴は絶対に損なわないようなアプリケーションの設計とすることをまとめています。
テスト方針や運用方針もルールとして定める
あとAWSをご利用されて皆さまなら、ある程度は感じられているかなと思いますけども、ある程度利用進んでくると、だんだんパターン化してきますので、そういったパターンを単純化するためにも、確実なものにするためにもテスト方針や運用方針等も一定のルールとして定めて、すべてAWSで動く仕組みは、これに則ることにする。ここに変更不変と禁止とする普遍の憲法のようなものに定めています。
ガイドラインですけれども、利用ガイド、設計ガイド、テストガイドということで、制約とか前提条件ですね。こういう設計をすることを推奨しますといったようなものをまとめたものがローソンの中では用意されていて、いろいろなとこに展開をしているという状況になります。
続けて標準化を推進しています。標準化の目的は、やっぱり設計から運用までを緩やかに、と書いてありますけど、ある程度統一していってシステム開発、システム構築の効率化、最適化を図る目的です。効率化と最適化を図れれば、必然的にプロジェクト期間の短縮化につながるだろうと考えています。
標準化の特徴としましては、AMIというインスタンスのイメージです。そういったものやクラウドフォーメーションなどで使うスタックをカタログ化して、横に展開すればすぐ使えるようなものになる。Aシステムで使っていたAMIを、Bシステムですぐ使えますといった形で、標準化と構築期間の短縮化を図ることをいま進めています。
それからもう1つは、AWSのマネージドサービスのパラメータはある程度数が決まっているので、こちらのほうも合わせてローソンのほうが標準化して、「こういう形で使うならこういうパラメータを使用しなさい」というところは、ある程度具体的に定めています。
フェーズに応じて基準とか標準を設定してきていまして、要件定義のフェーズにおいては、AWSのサービスの選定の基準を定めています。設計のフェーズに入るとAWSのパラメータ、シートのようなものがあって、その中にはある程度具体的にこういうものを使用しますといったパラメータまで落とし込まれたものになっています。
構築に入りますと、先ほど申し上げたとおりある程度AWSを使い込んでくると、そもそもはパターン化されてきますので、標準的な工程管理の意味でのWBSを作ってみたりとか、構築のためのチェックシートを作ったりとか、そういったワークロードの部分の削減という部分でも標準化を進めています。
また先ほど申し上げたとおり、AMIをカタログ化して、いま24種類のAMIを用意して、どのAMIを使いますか、どのAMIで動かしますかといったことを選ばす、そしてアプリケーションベンダーのほうに選んでもらう形でいま構築を進めようとしています。
また先ほど申し上げたとおり、最後テストフェーズでは、テストケースも標準化してしまって、ローソンのデータベースでこのサービスを使うんだったら、こういうテストケースをクリアするという標準もいま定めているところです。
新しい取り組みの一番の敵は「現行踏襲」
次に、いままでこうやってローソンAWSをどんどん活用していこうと、ローソンとしてどういうふうにAWSに接していこうか、アプローチしていこうか、四苦八苦してきて、ここに立っているわけですけれども、簡単にここまできたかというと決してそういうわけではなくて、いろいろなベンダーさんとかSIerさんの力を借りながらやってきたわけですけれども、やっぱりいろいろな壁にぶつかってきました。
皆さんも、いろいろ新しいこととか、難しいことに取り組もうとされると、何かしらぶつかると思うんですけど、特にシステム開発、システム構築の世界において、一番の敵は何かというと、「現行踏襲」というキーワードが出てくるんじゃないかなと思っています。
何か新しいことをやろうとすると、必ずどこからともなく現行踏襲でいいんじゃないかという言葉が聞こえてくるかと思います。この現行踏襲は魔法のようなものですよ。その言葉が出ると、なんとなく集団催眠術にかかったかのように、なぜかこの言葉を聞くと、なんとなくみんな納得してしまって、そうだなと。現行踏襲でいこうかと。今回はやめとこうみたいな流れになってしまう。こういったことが、僕らがデータベースの検討を進める上では一番の障壁になりました。
現行踏襲は決していいものではないと説得していくのかとか、あるいは打破していくのかは、実は今回のAWSの利用を進める上での大きなポイントになりました。あらためて現行踏襲によって何が守られるのか、何が嬉しいのかを考えると、やはりその現行踏襲によって過去の正当性は保たれるんじゃないかと思います。
例えばですけれども、いままでの情報システム部が既存のオンプレミスのシステムを作るときに、RFPで何々も満たすこと、99.99999だとか、何分以内に戻すこととかいろいろ書かれたりします。
あるいは、それに対して提案するベンダーさんも、これを実現しますって書いてきて、設計書にもそういった内容が書いてあるんですけれども、実はその実際の利用状況を見てみると、決してそうなっていなくて、「99.…あれ」みたいな形で、全然動いてないじゃないかといった形で乖離があるケースがあります。
そういった過去の正当性を保つために現行踏襲とは非常に使いやすい言葉ではないかなと思っています。それから、オンプレの止まらないとか、信号のようなもの、オンプレは絶対安全であるとか安全神話に守られていると、情報システム部にとって非常に楽な環境でして、いままでのものが安全ならば、そのままでいいと考えるのは、非常に理にかなった話ではあるんですけれども、そういった安全神話に守られていたいのかなと思っています。
それからやっぱり新しいことに取り組もうとすると、わからないとか、できない部分がどうしても出てきてしまう。人間的にはそういったものはあまり外に見せたくないので、そういったところから避けよう、そういった文化を避けようという心の部分はあるのかなと思っています。
「調達が間に合いません」は魔法の言葉だった
あとは3つ目、環境とか関係性も現行踏襲で守られるのかなと思っています。実は、この辺が一番抵抗。抵抗というと言葉はあれなんですけれども、ハードルが高い部分なのかなと思うんですけれども、いままでシステム構築を進めてください、システム開発を進めてくださいというと、調達が間に合いませんというのが魔法の言葉で、何かをぶち壊す1つのキーワードなんですけれども、AWSを使うことによって、この調達が間に合わないって言い訳ができなくなるんですね。
あと難易度の高い設計をしなければいけないのでベンダーに任せましょうという話もいろいろされているかと思いますけども、過去にもあったと思うんですけども、AWSを使うことによってある程度そういったものは自分たちでできてしまう。
そういった情シスの丸投げ体質とか、基盤部門と開発部門の暗黙の壁が現行踏襲というキーワードによって守られてしまうので、何となく皆が集団催眠術にかかったように、なんとなく現行踏襲でいいかという雰囲気になるのが、やってみて感じたリアルな感想です。
それで、こういった自分たちがやってきた中でハードルの高い、現行踏襲を打ち破るために何が必要か。これ、ありきたりではあるんですけども、やっぱりチェンジするしかないんですよね。やはりまず自らがチェンジをして、そのチェンジした自らが中心になって周囲を巻き込みながらチェンジの範囲を広げていくことがやっぱり重要でした。
自分で自己満足では意味がないので、チェンジすることによって何が変わるのか、何ができるようになるのかを粘り強く、周囲に展開していくことは非常に重要だと。その中には上司に説明をしたり、関係部門の了承を得たり、泥臭いところもやらなければいけないと思いますけど、とにかくチェンジする、考え方を変える、取り組み方を変える、視野を広げるとかに取り組むことが非常に重要だとあらためて感じています。
AWSの導入にあたってはマインドを大きく変えなければいけない
チェンジをする上で重要なのは大きく3つあるかと思います。これもいろいろなところで言われていることだと思うんですけども、やっぱりマインドを変えなければいけないところ、それから設計もやはり変えなければいけない。
それから関係性、先ほども言ったように関係性も変えていかなければいけないところがあると思います。やはり、いままでは作るところに主眼が置かれていたオンプレミスが、AWSによって、使うことによっていろいろな前提条件が変わってくると思います。まとまらない仕組みを徹底的に目指していた、オンプレミス。
止まるのを前提に作らなければいけないAWS。こういったところは、大きくマインドを変えないとそもそも受け入れられない発想になってしまいます。それから今までの設計で当たり前だったことが、AWSでは当たり前ではなくなります。
またいままで当たり前ではなかったものが、AWSでは当たり前なってしまいますので、その柔軟な発想。180度違うところからものを見て、いや裏を正せば、それは正しい結果になるという発想の転換ができるのは設計の場面でも求められるかなと思います。
最後に関係性ですけれども、やはりAWSを使うことで、インフラとアプリケーションの境界が、サービスが結構多いので曖昧になってくるケースがあると思いますけれども、インフラ担当者はアプリケーションをより知ろうとしなければいけませんし、アプリケーションの担当者はよりインフラを知ろう、AWSを知ろうとしなければ、この辺の関係性はうまくいかない。
つまり、チェンジすることで基盤と開発部門の壁がだんだん取り除かれてくる。そして自分たちできることが増えることによって、いままでシステム開発の実験をベンダーに握られていたならば、あらためて自分たち情報システム部の手に奪還するチャンスになるといままでの経験では感じています。
具体的にはどう変えていくのかを細かく書いてみました。マインドチェンジって何かというと先ほど申し上げたとおりです。現行踏襲ではシステムを構築するものでした。AWSではこれからシステムを活用する、使うものなりますので、マネージドサービスを徹底的に優先利用していきましょうと、有効活用していきましょうといった発想のチェンジが必要です。
あと、いままでのオンプレミスは何が何でも24時間365日、99.999の稼働率であること、5分前に戻せることが要件としてなってきたと思うんですね。止まることなんかまかりならんとよく言われた言葉だと思いますけれども、AWSを活用するのであれば、影響がないなら止まってもいいと。自動復旧前提になってればいいんじゃないかという発想の転換が必要です。
例えば、オンプレミスのシステムで、監視で何か障害がありました。サーバが死にましたっていうのに気がついて、復旧するまでの時間に何分かかっているのかをいろいろ皆さんと計測されていると思うんですけれども、AWSの例えば自動復旧ですと、長くてアプリケーションのデプロイまで含めていろいろ考えると、10分、15分かかるケースもあるかもしれませんが、最短であればもう5、6分の世界で立ち上がってきますし、RDSの世界でも同じく5、6分、5分か10分で立ち上がってきます。
AWSですと、いままでのレベルで障害を感知、検視、監視しようとしていると、気がついたときにはもう復旧しちゃっている。この復旧しちゃっている内容を、あらためて監視しなければいけないのか、調査しなければいけないのかと。そういったとこに時間を割くんだったら、どんどん死んでも起き上がるような仕組みを考えたほうがいいんじゃないかという発想の転換が必要ではないかなと考えています。
性能試験とサイジングの繰り返しが必要
もう1つが、現行踏襲ですと早期にきっちりサイジングしましょうという流れがあったと思います。とにかく、諸元を満たすようなサイジングを最初にやらなければいけない、そして、すぐ調達をしないとプロジェクトのクリティカルパスになってしまうということで、最初にやっていましたけれども、AWSを活用するのであれば、まずは最初に最小構成で動かしてみてノックアウト条件がないのか、アプリケーションの勘所がきちんと動くのかを試しながら性能試験を繰り返す、そしてサイジングをする、もう1回性能試験、サイジングをするのを繰り返していく発想が必要なのではないかなと思います。
それから、システムは使い続けなければいけない。あまり利用されていなくても費用を入れてサーバを動かし続けて、あるいは無理やりでも何かを載っけて動かし続ける努力を皆さんされていると思うんですけども、AWSの場合は不要になったら捨てることができます。ここに書いていますけども、いらなくなったインスタンスを右クリックして削除してしまえば消えてしまいますので、簡単に作って簡単に消す考え方が重要ではないかなと感じています。
続いてチェンジの設計です。設計として、これもいろいろなところで言われているので私がこの場であらためて細かく言うつもりはありませんが、いままでやっぱりIPアドレスでアクセスするのが基本的には求められていたと思います。AWSは基本的にFQDN名前解決をしなければいけないとなりますので、その辺の発想の転換が必要です。
1つ注意が必要なのはAWSに直接アクセスしてくるデバイスが名前解決できればいいのかというと、ただ単にそういうわけではなくて、その中間にいるシステムも名前解決ができていないと意外にはまるケースがあります。
私たちのとあるプロジェクトも、端末からサーバ、AWSの仕組みには名前解決ができているんだけれども、その中間にいる仕組みが名前解決ではなく、中にキャッシュを持っちゃっていて、そのキャッシュがずっとIPアドレスが変わることを気がつかずに、投げ先がなくなってしまって通信ができないというエラーがあったり。
そういうのがJavaの中に書かれていたりすると、なかなかインフラ側では検知しにくくなったりするので、そういったところへの気配りも重要になってきます。
共有ディスクではなく、S3の徹底活用がポイントに
あとは現行踏襲ですと、でっかいストレージをどかんと構えて共有ディスクで絶対死なない仕組みみたいな感じで動かしていますけれども、AWSを使うとなるとデータは基本的にはEC2、EBSの腹には持たずにS3を徹底的に活用していきましょうというのがポイントになってくるかと思います。
あとは現行踏襲。こちらもまた先ほども出ましたけれども、ピーク特性でサイジングをしていたものはAWSだったらスケールアップスケールアウトで対応すればいいんじゃないかと。ポリシーに応じて多くしたり大きくしたりという形で使っていけばいいんじゃないでしょうかと。
最大何とかTPSってよく諸元で求められているかと思いますけれども、そういうのに合わせてサイジングしてしまうと、使わない期間がどうしても出てきてしまいますので、そういった部分をなくしていこうという設計、発想の転換が必要だと思います。
あとはセッションステートという話と、AWSだったらセッションステートレスにすべきですねという話もあるかと思います。いままでですと、とある通信はとあるサーバに必ずいきなさいといった割り振りをしていたと思いますけれども、いまのAWSのロードバランサーですと、リストコネクションで1番負荷の少ないところに自動的に割り振ってくれますので、そういった仕様に耐えられるようなアプリケーションの開発を目指していかなければいけないと感じています。
最後に関係性です。いままでやっぱりインフラとアプリケーションはここにVSと書きましたけれども、どちらかというと壁がありましたけれども、AWSはパーツが豊富です。境界がなくなってきますので、インフラとアプリケーションの人たちが連合で合同になって物事を考えていくことは重要になってくるかと思います。
また、難しい設計は既存ベンダーさんに依存していたところもあるかと思いますけども、これからはやはりAWSを使うんだったら情シス、システム開発、システム基盤が主役になっていくチェンジが発生すると思います。
いまでこそ、それなりにAWSを担いでくるベンダーさんもいるかと思いますけれども、やはりベンダーさんにはベンダーさんの自分たちの売り物がありますので、AWSが専門家というと必ずしもそうではない。そういった意味ではやっぱりAWSは情シスが主導で使い倒していくモチベーションになっていくことは非常に重要ではないかなと思っています。
情報システム部が自らのマインドを変えることが大事
こういった形で現行踏襲を打ち破ろうと、いろいろ四苦八苦していろいろな仕組みをローソンではいま構築中でございます。簡単にまとめますと、やっぱり情シスが自らのマインドを変える。そしてAWSを正しく理解する、現行との違いを理解するサイクルを回しながら、最後は自分の周囲にいる人間を巻き込んでいろいろな環境を変えていく。
そうすることによってチェンジが浸透してAWSの利用が進む。AWSの利用が進めば情シスが主導権を握ってシステム開発ができるようになる。上質のバリューが上がることでいろいろな相乗効果が得られると我々は考えています。
ぜひ、いま現行踏襲で二の足を踏んでいる方がここにいらっしゃるのであれば、AWSに一歩足を踏み込んで、自分たちのバリューを上げる努力とか工夫とか、違った観点から取り組んでいただければなと思います。
参考までに、チェンジとかチャレンジしろとか言っても、「どっから手つけるねん」という話もあると思うんで簡単にやってきました。これ、私たちもこういうやり方をしてみたことあるんですけども、まず調査をしてみます。過去の要求仕様を、まず調査します。そして、その後に現状の本当の姿を比較してみます。
過去の要求仕様が、例えば稼働率が復旧目標とか使用率あると思うんですけれども、先ほど言った99.999とかピーク時でなんとかだとか、いろいろあると思うんですけども、現在の本当の姿を見てみると、実はそんなに当時求められていた仕様を使い切ってないケース多々あると思うんですね。
そういった乖離が大きいシステムというのは基本的にはAWSとの相性は二重丸だと私は感じておりますし、意外にそういったところではその説明のしやすさもあるんじゃないかなと思いますので、できればこういったところから調査をしてみてAWSに移行しましょう、コスト削減できますよ、という展開もあるんじゃないかなと考えておりますので、ぜひ参考にしていただければと思います。
最後に、AWSの活用に向けて、私のいままで使ってみた経験を表してみました。AWSを利用してみてなんですけれども、とあるシステムの我々の中で一番大きなシステムなんですけど、それをAWSで作ってみたときの課題の発生要因をまとめてきました。
実は一番問題が多かったのは、やっぱOSSで苦しめられているケースが多くて、皆さんもOSSはそれなりに苦労されているのかなと思いますけれども、それからいろいろなステイコールは出てきますので、そういったところとのコミュニケーションミス、意思の疎通が図れていなかったとか、そういったのは非常にトラブルとしては多くて、7割方こういったもので占めていたと。
いま一番安定して動いているのはAWS
じゃあAWSのトラブルで何があったのかっていうと、たかだかAWSの10パーセント程度しかシステム開発中にはなかったと統計が取れています。AWSの固有の問題といっても知っていればどうにかなるような問題も多くて、別に改善できないとか回避できないようなものかというと必ずしもそういうわけではなくて、単純に我々のスキル不足だったところも出ていますが、意外に使ってみてAWSさん安心できる仕組みなのかなと思っています。
先入観としてAWSはすぐ止まるんじゃないかとか、すぐ動かなくなるんじゃないかとか、自分たちの意思通りに動かないんじゃないかというのはあるかと思うんですが、いま一番安定して動いているのはAWSなんじゃないかなと思っています。
裏を返すと、死んでも気がつかなければいいやと思っているからというのもあると思うんですけれども、業務的には仕組み的には継続して動き続けているのが現状の感想で、安定して動いているなというのが正直な感想です。
あとは、AWSを使ってみて一番やっぱりメリットを感じたのは、いろいろとスケジュールが皆さん立て込んでくると思うんですけども、スケジュール通りに進むプロジェクト、果たしてここにいらっしゃる皆さんでどれぐらいの方が経験してきているのかなと非常に疑問なんですけど。
だいたいが後ろが変わらずに期間だけ短くなっていて、どうする、どうするって話になるかと思うんですけども、このプロジェクトもそういう状況になりましたけれども、そこへAWSのメリットを生かしてあまりお見せできるようなスケジュールではないんですけれども、一気に環境を4面、5面作ってしまって、そこで同時にテストを走らせることをやって期間どおりに間に合わせるような工夫もできています。
こういった安定して使えるAWSと、その拡張性が高い、弾力性が高いAWSは我々にとってはメリットがあるのかなと思っていますし、こういう活用の仕方、こういうデータに基づいた活用の仕方というのはこれからもどんどん進めていきたいなと感じています。
最後にローソンのチャレンジとAWSへの期待をまとめました。ローソンはこれからクラウドファーストをますます加速させていくつもりです。次世代のシステムをクラウドとともに作っていく予定です。
そして、いままではオンプレミス、閉じられた世界でのシステム構築だったんですけども、誰でもいつでもどこでもアクセスできる環境をクラウドで作っていきたい、それをAmazonと一緒に作っていきたいと考えております。
駆け足でしたけれども、ローソン進藤の発表はこれで終わりにしたいと思います。どうもありがとうございました。
（会場拍手）
