スタジアムから生まれるJAWS FESTA 2018伝説 第4回

テクノロジーの選択に必要な考え方をAWSエバが語る

AWSを利用すべきもう1つの理由は「メカニズム」の実装である

セキュリティの自動化「Security by Design」が必要な理由

　もう1つの懸念はセキュリティだ。Infrastracture as Codeのコンセプトを利用し、エンジニアが好きなときに、必要なリソースを調達できるようになった場合、セキュリティの懸念は高まる。こうしたセキュリティの実装を自動化するため、AWSでは「Security by Design」というコンセプトを提唱している。

　SoRを代表とする従来型のシステムは、モノリシック（単一）で巨大なシステムになる。「マイクロサービスの台頭により、なにかと悪者扱いされるモノリシックなアーキテクチャですが、ある程度小規模であれば、メンテナンスもしやすいし、十分に機能します」と亀田さんは語る。しかし、ユーザーが増え、ビジネスが増えてくると、一人の人間が見られる限界を超えることになる。「システムが破綻するか、社内でエースと呼ばれるエンジニアが辞める段にいたって、この会社は終わることになる」（亀田さん）。アプリケーションがモノリシックなため、ある程度の開発者が用意できても、どこかのメンテナンスが終わらないと、次のメンテナンスが行なえない。

　これに対して、最近のマイクロサービスアーキテクチャはアプリケーションを巨大なシステムとして定義するのではなく、機能や関数単位に分割して開発する。あらかじめ連携の経路を決めておくことで、開発・運用を並行に行なえる。AWSでも、こうしたマイクロサービスに基づいてサービスが開発されているため、昨年は1430回を超えるバージョンアップを無停止で実現しているという。

最近のマイクロサービスアーキテクチャ

　Infrastracture as Codeでは、アプリケーションをデプロイするタイミングで、実行するITリソースをプロビジョニングするというのが基本概念だ。とはいえ、Infrastracture as Codeは必ずしもクラウド上での実装を必須とするわけではなく、潤沢なリソースを用意すればオンプレミスでも実現できる。ハイパースケーラーと呼ばれるクラウドの場合、こうしたリソースが事実上無制限に利用できるため、利用しやすいというだけである。

　しかし、クラウドがあれば、DevOpsのような環境は実現しやすくなるのは事実。アプリケーションの実行環境を複製し、バージョンアップ時に動的に切り替えるさせるいわゆるBlue/Green Deploymentなどは、リソースに制限があるオンプレミスより、リソース確保の柔軟性が高いクラウドの方が導入しやすいはずだ。しかし、前述したとおり、こうした自由度を開発者にもたせると、セキュリティのリスクが生じるのも事実だ。

　これに対して、AWSはセキュリティを自動化するサービスを用意している。たとえば、AWS Configを使えば、起動できるOSやストレージの暗号化、SSHの禁止など通信経路の制限、バックアップの自動化、パスワード管理ルールなどのポリシーをセキュリティ管理者が決めて、ユーザーグループに適用できる。また、AWS CloudFormationでも、さまざまなセキュリティ設定やコンプライアンスを適用できる。「あらかじめセキュリティ設定が施された環境を、誰が、いつ作業しても同じように作れる。セキュリティツールを環境に組み込んだ上で、開発者に自由を与えてくださいというのがAWSの基本的な考えです。これがSecurty By Designです」ということで、シフトレフトやセキュリティオートメーションと同じようなコンセプトになるという。

メカニズムを実装するための機械学習

　企業が機械学習に取り組むのも、メカニズムを実装したいからにほかならないという。連続的なインプットに対して、人間の手を介さず、付加価値のあるアウトプットを返す機械学習はまさにメカニズムそのもの。ビジネスにおいては、リコメンデーション、言語や画像認識、データ分析などが幅広く用いられている。「現在これらの領域では、こなれた人間の方がアウトプットの精度は高い。でも、なぜ機械学習を導入するのかと言えば、やはり仕組み化したいんですよね。人間の場合、機嫌が悪かったり、疲れればミスも起こる」と亀田さんは指摘する。

　従来のルールベースのプログラミングに対し、機械学習は大量のデータからパターンや洞察を導き出す。データを収集し、仮説を生み出し、学習を回し、推論プログラムをサービスに実装。ユーザーからのフィードバックを受けて、効果を検証し、さらに精度を高めていくというサイクルだ。このサイクルを回すのにおいては、リソースの柔軟性が必要になるため、クラウドが向いているというわけだ。

　そして、AWSではこの機械学習のサイクルを効率的に進めるため「Amazon SageMaker」というツールを提供している。「データサイエンティストや開発者にもかかわらず、その多くはインフラのメンテナンスや溜まったデータの処理に追われ、推論エンジンをWebサービスに組み込む仕事まで任されている」（亀田さん）というのが開発の背景となる課題だ。これを解消すべく作られたAmazon Sage Makerでは、機械学習のサイクル全体を継続的に回すための開発・学習・推論の環境が用意されており、TensorFlow、Caffe2、mxnet、KERAS、Microsoft CNTK、Chainer、PYTORCH、GLUONなど主要なフレームワークがサポートされている。

機械学習のモデルを構築・学習・運用できるAmazon SageMaker

技術の選択はメカニズムを実装できるかが鍵

　最後は11月末に近づいたAWS re:Invent 2018の予告だ。近年はサーバーレス、IoT、VUI、データレイク、機械学習（ML）、コンテナなどさまざまなキーワードに対応するサービスが発表され、昨年は新サービスは40以上に上る。もちろん、亀田さんは新発表に言及することはなかったが、「Bio Analytics」「Self Repair System」「Holographic Display」「Quantum computing & Encryption」などのトレンドキーワードだけは披露する。「これらのバズワードのうち、どれかはなくなり、どれかは定着するが、われわれはなにを中心に勉強し、キャッチすべきなのかを考えると、やはり今日のメカニズムという話に戻る」と亀田さんは語る。

亀田さんが披露したトレンドキーワード

　年々変わる技術トレンドと次々登場するサービス。亀田さんは、「どの技術を用いれば、課題を解決できるのかが今までのアプローチ。しかし、新しい技術を使うのであれば、どんな課題を解決できるのかに加え、自動化できるかどうか、自分がいなくても同じ結果を出し続けられる技術なのか、こういったことを技術を精査すべき」と語る。メカニズムの実装に資する技術なのかが1つの観点というわけだ。

　そしてもう1つは、学習サイクルを作っておくこと。「さまざまな情報を自分の中でささっと判断する。試すのか、試さないのか、結果をアウトプットしておくのか。こういった学習サイクルという仕組みを自分の中で作っておくことが求められる時代になっています」と語る。人口減少と労働力不足の中、同じ時間で大量のアウトプットを出すために、メカニズムを作れるかどうか。「これをチェックすることで、クラウドコンピューティングをより楽しめるのではないか」とアピールし、亀田さんのいい話は今日もオーバーランせずに終了した。

■関連サイト

• JAWS FESTA 2018登壇資料（亀田治伸さん）