非機能要求グレードから見るオンプレとクラウドの違い
富岡秀明氏（以下、富岡）：はじめまして、富岡と申します。今日のお題は、「クラウドヂカラ #AWSセミナー〜エンジニアに求められる本当のスキルとは！〜」ということで、「オンプレとAWSの違いってどんなところか」ということを、あまり技術的なところではなく、もう少し上流からお話できればと思います。
最近、よく自分のところに相談が来ます。
「今までアプリやインフラのエンジニアをやっていたんだけど、最近お客さんが『AWSをやりたい』とか『クラウドをやりたい』とか、いろいろ言ってきます」と。
そこで「自分にもできるんですか？」「難しいんじゃないんですか？」という話がいろいろと出てきます。
優しくない人だったら、「Google is Your Friend.」と言って終わりにする人もいるかもしれないんですけど、僕はいつももう少し違う説明をしています。
僕の1つ目の回答としては、「オンプレの設計ができる人は、AWSでも十分に設計ができる」ということです。逆に、オンプレの設計がちゃんとできてない人は、AWSでも変わらとも言えます。
2つ目の回答は、やっぱりどうしても、「AWSとオンプレでできることとできないことがある」ということです。ここはしっかりと把握して、できないことを「できますよ」と言わないように心がける必要があります。
3つ目の回答は、機能はGoogleが教えてくれるということと、検索キーワード「＋BlackBelt」を付けると、AWSの技術資料がけっこう出てきます。AWSの研修に行った方は、みなさんご存じだと思いますが、いろいろな資料があるので、それを読んでいただくといいと思います。
今日ここで細かい技術の話をしないのは、今日勉強しても、AWSの細かい話は明日変わってしまいます。ウチのメンバーも「勝手に変えんなよ」とよく文句は言っているんですけど（笑）、逆に言うと、AWSとしては、手順書をつくったり、暗記するということは、少し時代と違うのかなと思っています。
なので今日は、「AWSでできることとできないこと」を非機能要求グレードというものに従って説明してみたいと思います。
機能要求と非機能要求の違い
非機能要求グレードは、日本のベンダーやIPAが一緒になって、ITインフラの機能ではない部分をまとめた規格のようなものになります。
例えば、最近僕がよく観ている「AbemaTV」でいくと、「ユーザーが過去のテレビ番組を自由に検索できるようにしたい」「倍速再生できるようにしたい」「視聴履歴からおすすめ番組をメールで送信したい」というような、エンドユーザーに直接提供するものが機能要求になります
その次に、「同時配信数が年間30パーセント増加しても性能が変わらないようにしてほしい」「24時間365日ノンストップで配信してほしい」「キャンペーンの時は通常の10倍のアクセス数を処理できるようにしてほしい」という要求が最近よくありますが、これらのシステム基盤（インフラ）で担保するようなものが非機能要求になります。
非機能要求グレードの中身 ①可用性
では、非機能要求グレードの中身が何でできているかというと、まず1番目は「可用性」です。
例えば、「Amazonでは、Amazon EC2の可用性がどのくらいなのか」「Amazon S3のSLA・サービスレベルがどのくらいなのか」ということは、ホームページ上に個々に定義されていて、「万が一それ以上に停止した場合は、その時間のお金を返します」と言ってくれてはいます。
そのあたりの保証はされているのですが、あくまで個々のサービスレベルになっているので、お客さんからの要求がもう少し高ければ、Webサーバーを複数台並べて可用性を高めるとか、データベースだったらアベイラビリティゾーンを分けて、複数のDBを持って、片方が壊れても大丈夫なようにしておくことが必要かなと思います。
ただし、ここはオンプレもAWSも一緒なんですけど、人的な災害はどうしようもありません。これはお客さんにもしっかりと言っておいたほうがいいと思います。
みなさん使っているかもしれませんが、去年アメリカで「Slack」が長い時間止まっていました。
幸い日本はほとんど影響を受けていなかったんですけど、これはAmazonのエンジニアがS3の一部機能をシャットダウンしたら、連鎖的に全部が落ちてしまって、復旧をかけようとしたんだけど、復旧がたくさん同時に上がろうとしたので、なかなか上がらなかったという話だったと思います。
結局オンプレでも、運用している人が間違ってシャットダウンしてしまうということはあるあるだと思うんですけど、Amazonでも起きるものというところで、このあたりは覚悟しておく必要があるかと思います。
非機能要求グレードの中身 ②機能・拡張性
次に、性能・拡張性です。みなさんの中で、「オートスケール」という言葉が好きな方はいらっしゃいますか？
（会場挙手）
いますよね（笑）。「何かあった時に、サーバーがどんどん増えてアクセスをさばいてくれたら、こんなすばらしい機能はないじゃないか」というのものがオートスケールという機能です。
ただし、実際にはそう簡単にはいかなくて、サーバーが増えたところでそこに入っている中身が古かったら意味がないし、「それをどれだけ素早く最新化できるのか」といったポイントがあります。
あとは「拡張性」と言っているんですけど、けっこう使えるのは、（サーバーを）減らす方向です。
これもよくお客さんから言われると思うんですけど、「AWSを使ったら安くなるの？」という話があると思います。
オンプレの場合、1回買ってしまうと減らせないというところがあって、AWSはそこの部分を減らせるということがメリットかなと思います。
実際、最近僕がやっているプロジェクトでも、もともと十数台あったサーバーを半分ぐらいにしました。
予想よりアクセス数が少なくて、ビジネス的には気の毒な感じがするんですけど、費用も半分になることによって、お客さんもサービスを継続できます。
さらに、「その先を考えて、また増やせばいいや」という考えになってもらえたので、自由に減らしたり増やしたりできるのが非常にいいところかなと思います。
ポイントは、コンテンツ最新化の方法です。
増えるといっても、サーバーが勝手にコピーされていくものではなく、どこかの時点のイメージから新しく起動されていくかたちになります。なので、そのイメージを常に最新化しておく、あるいは起動した時に最新の情報・コンテンツを取りにいく仕組みを入れておかなければいけません。
なので知らずに、「単純にすぐ増えて、アクセスがさばけますよ」という話だけでは終わりません。意外とこのあたりの作り込みや運用がうまくいかなくて、「オートスケール使えないじゃん」ということはよく聞く話かなと思います。
非機能要求グレードの中身 ③運用・保守性
次に、運用・保守性です。これはけっこう重要です。最近も僕の知っているところで事故が起きたんですけど。
AWSのマネージメントコンソールは、オンプレではあり得ないと思うんですけど、インターネットがあればどこからでも接続できます。
普通はデータセンターなりサーバールームの厳重なセキュリティがあって、その先のサーバーに行って、初めて電源ボタンを押したり、機器を触ることができると思うんですけど、AWSはインターネット越しに、言ってしまえば漫画喫茶からでも、お客さんのシステム全部を落とすことも不可能ではありません。
なので一般的には、そうならないために、マルチファクター認証がかけられるのかなと思っています。
ここまではいいんですけど、その次に、最近事故ってしまったものがあって、お客さんは通常、1つの口座でAWSのアカウントをつくっています。
もっと大規模になると、開発用の口座と本番用の口座で別で課金されるようにするんですけれども、そこが1つだと、最終的には1つの画面で本番環境も開発環境も触れることになります。
実際、サーバーのシャットダウンはその下のアカウントで制御していたんですけど、制御がしづらいネットワーク部分のところで、開発環境だと思っていじったら本番環境で、本番環境が止まってしまったという事件が身近で起きました。
なので、このような運用・保守性、アクセス制御などには非常に気を付ける必要があるのかなと思います。オンプレでもありますけど、（AWSは）さらに敷居が低く、何でもできることがメリットにもデメリットにもなるのかなと思っています。
これもよくアプリケーションチームから言われるんですけど、RDSというサービスでOracleのインスタンスが提供されていて、「Oracleのバージョンって何なの？」とか、「パッチはどこまで当たってるの？」とか、「PSRはどこまで当たってるの？」とか、それによってアプリが動く・動かないということがあるので、「教えてください」とよく聞かれるはずです。
普通であれば、開発時に1回バージョンを固定してしまえば、よほど大事がないかぎり、当てても年1回とか、数年に1回とか、最後まで当てないというところもけっこうあると思います。
そうなんですが、この「当てる・当てない」は、基本的にAmazonのポリシーに則ります。まあ、さすがに一番上の12cとか、18の部分は当てようとはしてないんですけど、セキュリティパッチ系やPSRなどは、「何か問題があって、Amazonが当ててなかったら問題だ」という世の中的な動きがあり、基本的に当てようとしてきますので、「ここはもうこういうもんだよ」とアプリケーションチームに必ず言っておく必要があります。
もちろんある程度大きいパッチは猶予期間があるので、「その間にちゃんとテストしてください」とか、「検証を通ってからやりましょう」ということは言えると思います。
非機能要求グレードの中身 ④セキュリティ
最後に近づいてきましたけど、セキュリティです。「Amazonのセキュリティはどうなっているのか」というと、「Amazonにお任せです」というのがまず第一声なんですけど。
データセンターの対策などは、基本的にAmazonがやってくれています。
その後の細かいアプリケーション層やOSユーザーのアカウントなどで防御するところは、「全部あなたたちでやってね」と言われています。
AWSでは共有セキュリティ責任モデルが定義されており、システムセキュリティの責任分界点が明確になっています。「ファシリティの部分はAmazonが担保します。それ以上は知らん」ということになります。
このあたりも自分たちで全部いじれるわけではないので、「一般的なISOの○○に則っていますよ」とか、クレジットカードの情報などを扱う時に、PCIDSSという規格があると思うんですけど、「そのあたりにも対応できますよ」ということでUFJが使ってみたり、ということもあると思っています。
非機能要求グレードの中身 ⑤環境・設備
次に、環境・設備です。
AWSはTier Ⅲ+ガイドラインに従ってデータセンターを運営しています。Tier Ⅲというのは、データセンターのファシリティの規格です。
Tier Ⅲの上のTier Ⅳは「データセンターの障害があったとしても、年間99.99パーセントの稼働率を保証します」という規格です。なのでTier Ⅲその下です。ただ、Amazonは「実質はTier Ⅳになっています」と言ってくれています。
5年後に生き残れるエンジニアの条件とは
最後にまとめです。「じゃあ、AWSはどんな時に使ったらいいの？」というところなのですが、一番の売りはやっぱり（サーバーを）増やしたり減らしたり、ビジネスの需要予測ができていない段階でもスタートしなければいけない場合には、本当に打ってつけだと思います。
需要予測がきっちりできているなら、僕はオンプレのほうがぜんぜんいいですし、コスト的にも5年経ったら半分でできるんじゃないかなと思ってます。
その代わり、例えば、「需要予測ができていないのに、オンプレでサーバー50台を入れました。実は10台しか使っていません」ということになると、ほとんど損になってしまいます。
それであればAWSで10台から始めるのが一番いいと思っています。
最近、またオンプレ回帰の話もありますが、なぜかというと、例えばエンドユーザーの業界にとっても、ITインフラを他社に押さえられてしまうというところ、自分のビジネスの展開やスピードが変わった時に、自分色にカスタマイズできないというところがデメリットになってきている場合もあります。
そのようなところで、オンプレ回帰もけっこう来ているとは思います。なので、使える場面・使えない場面をしっかりと考えて、使用していただくのがいいのかなと思います。
最後に「5年後に生き残れるエンジニアとは何か！」ということが、ホームページの副題になっていたかと思いますが、少しの無理と、情報の蓄積を使って、新しいことにどんどんチャレンジしていくという、ダイナミックシナジーとオーバーエクステンションをできる人が、5年後でも10年後でも生き残っていくと思います。以上になります。ご清聴ありがとうございました。
（会場拍手）
