AWSとGoogle Cloudのベストプラクティス　設計の原則から品質の確認にも活用できる3つのもの

セッションの概要とアジェンダ

高橋修一氏（以下、高橋）：では「AWS＆Google Cloudを使ったシステム開発／技術選定のはなし」をします。よろしくお願いします。僕ですが、高橋修一といいます。アイレットのMSP開発セクションという部署で開発のエンジニアをしています。AWSはアイレットに入ってから触り始めて、だいたい5年ぐらい触っています。Google Cloudもここ1年ぐらいで触るようになりました。

今日はなんの話かというと、ちょっといきなり変な図で申し訳ないのですが。一番下の赤い人間が僕です。AWSやGoogle Cloudを活用して動くシステムを開発してます。その開発する中で得た知見とか、工夫してることなどを共有できたらと思ってます。

あと、AWSもGoogle Cloudもベストプラクティスがあり、それも日々見たり活用したりしています。こちらでもいろいろ得たこととか「最初からこっち見ればよかったよ」とか。つながるところがあるので、こちらも紹介したいと思います。

ということで、今日はまず最初のベストプラクティス。概要だけこんなにあるのでよかったら見てみてくださいという感じのと、こんなふうに使ってますと。その次に、自分の知見で1つでも役に立つところがあればいいなと思い、ちょっと共有します。

ということで、今日のアジェンダはこんな感じです。最初に僕がどんなことをしているのかを軽く紹介して、ベストプラクティスと知見の共有というかたちで進めます。

自己紹介

僕のポジションです。MSP開発という部署で、直接お客さまの何かシステムを開発するわけではなく、お客さまの環境を構築したりとか運用してる部隊がその作業を効率化したり、一部自動化するような社内サービスを作っています。お客さまの環境はAWSだったりGoogle Cloudだったりしますが、僕の作ってるサービスもAWSやGoogle Cloudです。大小いろいろありますが、サービス数は18個ぐらいあります。

直接お客さまとやりとりすることは少ないですがも、ちょっとでも効率よくできるようにしている部署になります。AWSやGoogle Cloud以外にも、外部の便利なSaaSなども使っているのが僕のポジションになります。ここで得た知見などを、今日共有できるかと思います。

AWSのベストプラクティス：Well-Architected

次がAWSのベストプラクティスです。Well-Architectedというものがあります。これはクラウドアーキテクチャのベストプラクティスをAWSがまとめているもので、だいたいどんな構造になってるかというと、5つの観点が柱です。

運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化があって。それぞれの柱に対して設計の原則、「運用コードとして実行するのは、手作業でスクリプト化して再現性のあるものにしましょう」というような原則が何個か書いてあります。あとはこれを組織、準備などの分野で分けています。その分野ごとに、また具体的なベストプラクティスがあります。

スライドの中のものでいうと、いい運用のために、組織としてこういうことが必要だということが書いてあります。「顧客のニーズ、評価」「ガバナンス要件、コンプライアンス用件をまず評価する」。そこに対して具体的なAWSからの提案のようなものが書いてあります。例えば、「AWSのTrusted Advisorで脅威を評価する方法があるよ」みたいなことを、けっこう具体的に書いてくれてます。

ちょっと中身をいくつかピックアップしてみます。技術選定というところで、どのサービス使うかですが、そういったことも書いてあります。

コンピューティング、どのように選択するか。どういうサービスがあって、どういう特色があるかをまず理解した上で選んでいくということで。インスタンス、コンテナ、関数などのほうがマネージドだと思いますが、こういったもののどれが合ってるのか書いてあったり。伸縮性、エラスティックなのを使うとかです。ストレージも同じように、特性と動きを理解して、いろいろな設定も理解してというところです。

ここでおもしろいなと思ったのが、両方ともメトリクスに基づいてというところがあって。メトリクスに基づいてコンピューティングニーズを再評価するとか、メトリクスに基づいて意思決定を行うところで、サービスなど、ワークロードの状況は変わっていくので、実際どういう使われ方をしてるかの指標値を見て、再評価するようなことも書いてます。

このあたりは僕はけっこう「やらな」と思って後回しにしていた部分があるので。ちゃんと書いてあって、そのやり方の提案が描かれてるので、けっこういいなと思ってます。

あとはサービスクォーターといって、割り当てですね。同時実行数や、そもそもその制限がいろいろかかっているので、それを理解した上でアーキテクチャを考えることも書いてあります。

あと、けっこう具体的なこと書いているところがあって。データのバックアップなどは、基本としてRTOとRPOによってそれを満たすようなものを作った・使うていうことですが、具体的なバックアップの方法などが書いてあります。Dynamoでオンデマンドバックアップとか、ポイントインタイムリカバリとか書いてて、あとは暗号化とかです。

あとは復旧など、自動的に「いろんな複雑な時はStep Functions使ってみるのもいいよ」みたいなことも書いてあります。ここは具体的なテンプレートみたいなものはありませんが、項目によっていろいろ粒度があります。

あとは定期的な見直しです。完全に技術的なところ以外の、運用周りなども、けっこういろいろ書いてあるなと思いました。

運用手順を定期的に改善する。ゲームデイ開いて、実際この運用手順でいけるか確認したり検証するのがいいよ、と書いてあったり。

新しいサービスが出た時に、今あるワークロードに対して「ここはこれに変えたほうがいいんじゃないか」みたいな評価をどうやってますか、という。ただ全部に対しては難しいと思うので、例として、影響の大きい、請求の10パーセント以上の価値を持つコアワークロードは四半期ごと、そうでないものは年に1回とかなど、提案をしてくれているので、読んだことない人は読んでみると何かヒントになるんじゃないかなと思います。

読んだ文章ですが、マネジメントコンソールからツールが使えて。先ほど出てきたような質問もここに表示されて、満たしてる・満たしてないチェックしていく。ここには書いていませんが、メモ欄みたいなものもあるので、自分のメモが書けます。こういうのを、チームでも会社としても使っています。

Well-Architectedをしばらく使ってみた感想

しばらくやってみてですが、けっこう網羅的に書いてくれているので、新規のシステム設計段階からとおしていると、考慮漏れの予防になります。全部を満たすのはけっこう難しいので、優先順位を決めています。

すでに動いているシステムに対してWell-Architectedをかけて。なかなか意識してない状態で作ったものでやると耳が痛いような思いをすることもありますが、けっこう今抱えてる問題は、「こういうことで解決できるかも」というヒントになったりします。

システムに手を入れること自体が難しいものでも、本体ではなく運用手順の部分をスクリプト化したり、運用手順をドキュメントにちゃんと書くようなこともあるので、手をつけにくいシステムに対しても、問題の可視化などの部分で品質が得られないかというので、けっこう役に立つと思います。

AWSの具体的なサービス名の提案も書いてありますが、わりと一般的なことが書いてあるので、弊社ではGoogle Cloudで使ってるシステムも、このWell－Architectedレビューをかけてたりします。

あとは「チーム」の計画や習慣の見直しになるということで、中には1個のシステムで考えるのではなく、そもそもチームとして定期的に分析するとか、タスクの進め方とかを変えないと対応できないようなことがあって。

やるかやらないかは自分で判断すればいいですが、チームも「もうちょっとこうしていったほうがいいな」とか、「ルールとか計画する時に、こういうことも考えないといけないな」ということで。システムだけではなく、チーム自体の改善のほうが僕は大きいかなと思っています。

あと、ドキュメントが整備されてきています。Well-Architectedは、最初に出たときの説明の文書は正直わかりにくかったですが、最近はけっこう前より具体的なことが書いてあったり、いろいろなリンクが追加されていて見やすかったので。昔見て「なんか合わないな」と思った方も、ちょっとまた見てみると合うかもしれないのでぜひ、という感じです。

Well-Architectedの活用方法

どうやって活用しているかです。ベストプラクティスに対して、社内でルール化されていたり、仕組みがあるものもあると思います。そういったものを当てはめていくと、「社内ルールでカバーできてるな」とか、「社内のこのシステムを入れれば満たせるな」とか。

会社内で配ると、みんな同じこと考えなくても「ここはこれ満たしてるな」とか「この社内システムは使っていなかったけど、ここで使うと確かにここは満たせるな」とかもわかるので、作ってみるのもいいかなと思います。これを作ることで「この表示のところ足りないな」というのもわかるので、という感じです。

Google Cloudのベストプラクティス：Cloud アーキテクチャセンター

Google Cloudのベストプラクティスで、まずCloudアーキテクチャセンターがあります。これが何かというと、僕は2つに分かれてるように見えたので、ちょっと分けて説明します。

1個はアーキテクチャフレームワークといって、設計の原則がだいたい4つに分かれています。卓越した運用、セキュリティ、信頼性、パフォーマンスと費用の最適化という感じ。先ほどのものと似ていると思いますが、そのGoogle Cloud版みたいなものです。ベストプラクティスで気にするべき観点などを書いてくれています。

Cloudアーキテクチャセンターでは、Google Cloudの具体的なサービス名で「こういうのを使うといい」というのをけっこう言ってくれるので、とりあえず試してみるかたちで、システム適用するのはやりやすいかもしれないです。

あとはリファレンスアーキテクチャというものがあります。実は僕、これをぜんぜん知らなくて。あまり使ったことがありませんでしたが見てみるとけっこうアーキテクチャの図など、いろいろなことが書いてあって。英語ですが、これもこれから見ていこうかなと思ってます。

Google Cloudのベストプラクティス：ソリューションデザインパターン

おすすめしたいのがもう1個あって、ソリューションデザインパターンというサイトがあります。先ほどのものと似ているように見えるかもしれませんが、いろいろなワークロード、例えばゲームや流通、交通機関やエンタープライズとか。それに対して、全部デザインパターンを出してくれています。

これの何がいいかというと、注意事項とかも出してくれるので。けっこう最後のほうに、普通にドキュメント読んでるだけだととなかなか気づかないものも書いてくれているので、僕はすごくいいなと思っています。

このページは確か2020年12月ぐらいにできたもので、それを初めて見た時、自分でいろいろ読んだり調べたり動かして検証して「あ、これはこういう時に使うんかな」「このパターンでもいけないのかな」と思ってたことが書いてあったので、見たほうがいいと思います。

ここでは実際のものを表示したい思います。

（デモ開始）

先ほどのものがクラウドネイティブアプリケーションで、デザインパターン詳細に記載されているものが、Cloud RunとCloud Firestoreの組み合わせです。扱いどころとかがちゃんと書いてあって。

具体例を書いてくれてています。アーキテクチャの図もあって、リファレンスのリンクもあってという、至れり尽くせりの感じです。

次に、利点です。Cloud Runはこういう利点があって、という特徴。どのくらいスケールするかとか、Firestoreも書かれています。

さらに「こういう場合には向かないよ」などの注意事項。時間の長いバッチプログラムなど、（タイムアウト時間の最大が）60分というのは最近事例になったので、そのことも書かれています。

サンプルコンフィグというところにQuicklabsという、ハンズオンできるサービスがありますが、リンクも貼られています。実際に手を動かして試してみたりできるので、すごくいいなと思っています。

（デモ終わり）

（次回につづく）