AWSとGoogle Cloudからみた技術選定の考え方と工夫　基本はマネージドでカスタムが効くものも活用する

開発・技術選定の基本的な考え方

高橋修一氏（以下、高橋）：今のがベストプラクティスで、ここからがちょっと僕の共有になります。基本的な考え方は一般的ですが、できるだけマネージドのものを使う。AWSであればコンピューティング、EC2よりもFargateとか。LambdaでいいのであればLambda。Google Cloudでは、Google CloudエンジンなのでCloud RunとかCloud Functionsとかに寄せる。

基本的にできるだけマネージドなものを使う。ある時だけもうちょっとカスタムの効くもの。ちょっと自分で面倒見ないといけないものを使うのも、やはり基本になってくるかと思います。

ただ、3rdのSaaSやソフトの活用もしています。できるだけ担保すべき範囲を減らして、開発の高速化やコストの低下を意識してます。

同じようなCI／CDやIaC、監視・モニタリングでも、それぞれAWS、Google Cloud、3rdがあるので、使い分けています。もちろん、例えばCI／CDのパイプラインはCircle CIで、デプロイはCode Deploy使うとか、そういう組み合わせもできます。

という感じで僕のチームは両方使うので、メインのロジックはAWS、Google Cloudで作って、デプロイや監視などはけっこう3rdのものを活用することが多いです。

3rdのメリットは、AWSにもGoogle Cloudにも対応してるものが多く、同じ方法で対応できる。チームで保守していく上で費用対効果がよくて、保守体制も組みやすいです。やはり専門のサービスなので、機能が豊富でかゆいとこに手が届くイメージがあります。

あと、プラグインなどの拡張機能がついてるものが多く、ユーザーがいろいろなものを公開してるので、けっこうできることが多い印象です。

クラウドの中に入っているものを使うメリットとしては、サービス連携が強く、権限やユーザーの管理がIAMで完結するのはけっこう大きいと思います。サービスのユーザーを作ったり、「その管理どうするの」ということを考えず、IAMユーザーで完結できるのがけっこう大きいかなと。

料金も、AWSやかGoogle Cloudの料金で、だいたい従量課金や何かしらの単位できます。SaaSだと「どのプランにするか」「その料金って、また別途気にしとかんといけないよね」とか。そういったことを考えなくていいので、それはメリットかなと思っています。

制約の確認

次はサービスの特徴を理解するというところで、まず制約の確認です。何ができるかはけっこうすぐわかりますが、何ができないか、どういう制限があるのかは必ず確認しないといけません。そこの把握が漏れた状態で進めると、けっこう大変だと思うので必要かなと思います。

その確認ですが、例えばFaaS。Cloud Function、Lambdaとか、同時実行数とタイムアウトとか。テーブルの数とかバケットの数とか、だいたい何かしら制限があるので、あとは受けられるリクエストの数です。このあたりも「似たようなサービスやけど、どう違うんやろ？」と見てみると、料金や用途に合わせて違ったりするので。

AWSもGoogle Cloudも調べたら出てくるので、触るサービスについては目はとおしておいたほうがいいかなと思います。その時に、割り当ての単位がリージョンごとに決まってるのか、アカウントやプロジェクト単位で決まってるのかも、ちょっと見ておかないといけないかなと思います。

このあたりの上限は、引き上げ可能なものがあれば、申請や設定をしても上げられないものもあるので、それも確認が必要かなと思います。

ただこのあたりのものも、アップデートによって「このぐらいまでできるようになりました」みたいな変更があることもあるので、気にしておいたほうがいいかなと思います。

特性の把握

あとは特性の把握です。例えばイベント配信。今の名前だと、イベントブリッジ、CloudWatchイベントですかね。ちょっとどちらか忘れましたが、SQSやSNSなどのメッセージ系のものは、だいたい重複配信されるものが多いと思います。

どういうことかというと、1回メッセージを送って、受信側が1回以上受信するということで、その1個のリクエストに対して複数回走ることがあるのを把握しておかないとまずいシステムもあると思うので、把握しないといけないかなと思います。

その配信の順番も同じなのか、入れ替わったりするのかも重要かなと思うので、このあたりは必ず確認したほうがいいのと、基本1回以上配信されるものが多いと思います。

重複実行したくない場合は、AWSだとDynamoDBの条件つき書き込みのテーブルで排他テーブルを作り、1回しか実行しないとか、そういう工夫が必要になります。

あとはデータの更新の結果整合性か強い整合性か。データを更新しても他のものがすぐ読みにいったら、まだそれが反映されてないとか。昔のS3などでは結果整合性だと思うので知ってる方も多いかと思いますが、これもけっこう重要な要素かなと思います。

あとは基本的には料金のかかり方です。何に対して、何と比例して料金がかかるか。たまに見落としてゾッとする時があるので、わりと丁寧に目をとおすか、開発環境をしばらく動かして料金を見たりするのがいいかなと思います。

制約も、アップデートで外されたりすることがあって。S3は2020年結果整合性だったのが、強力な生合成になって。「S3というものはそういうものだ」と勝手に思っていたので、けっこう感動しました。これで考慮しないといけないことが、けっこう減った人も多いんじゃないかと思います。ちょっとこれ字を間違えてますけど（誤：生合成→正：整合性）。

そのサービスがどういうメトリクスを持っているか

あと、そのサービスの特性を知るという意味で僕がよくやってるのが、メトリクスです。そのサービスがどういうメトリクスを持ってるかですね。AWSだとCloudWatch、Google CloudだとCloud Monitoringです。こういう実行数や失敗、今どれぐらい使ってるかという、自分の状態を吐き出すと思うんですが。

それを見ると、「わざわざそれを吐き出せるようにしてあるから、気にしないといけないんだな」とか、「これが上がる時ってどういう時だろう」とか。「そもそもスロットリングという仕組みがあるんだ」とか、理解の補助になると思います。これもドキュメントがあるので、サービスを理解する時にメトリクスを見るのもいいかなと思っています。

IaCで意識していること

意識していること・工夫。IaC、例えばCloudFormationやTerraformで、コードとしてインフラをちゃんと定義して書いて、それでインフラ作っていくものです画面でポチポチすると、実は裏でいろいろなものが作られていて。それに慣れていると、単純にIaCで「こういうインスタンスを作る」という一番シンプルな設定で、あとはデフォルト設定みたいな書き方をすると、コンソールでやった時に裏でいろいろやってくれている設定が、実は入っていないことがけっこうあると思います。

特にそのあたりを補助してくれるものももありますが、一番プレーンなCloudFormationなどが入っていないことが多いので。デフォルト値はなかなか勝手に変わったりはしないので、新しく追加された設定などは自分で書き足さないといけません。そこはけっこう気をつけたほうがいいかなと個人的に思ってます。例えば、S3バケットの暗号化や、開放オプションって何も書かないと有効にならないので。

あと見たことがあるのが、APIゲートウェイに対してAPIキーという、アクセスの制限のキーを生成していますが、APIキー必須フラグがついてないと、実はそのAPIキーを使わなくても呼び出せてしまう。これは事故になってしまうかなと思ったりします。

Lambdaをイベントで呼び出す時に、画面でポチポチやるとLambda側にも呼び出される許可が付与されますが、一番シンプルなCloudFormationなどでは自分でその許可の定義を書かないといけないので、動かしてみたら「あれ？　呼び出されないぞ」「マネジメントコンソールでポチポチやった時は動いたのに」みたいなのことがあったりします。

これに関しては動かないのですぐわかりますが、セキュリティー面はついてないことに気づかない可能性があるので、注意がいるかなと思います。

「このあたりの制限をつけたい」となって慌ててつけたりすると、アクセスのガードが増えてしまいます。今まで動いていたことが動かなくなる事故になる可能性もあるので、これはどういう意味かを理解して、開発環境や検証環境で動作を見た上でやらないと、ちょっと危ないかなと思います。

こういうのはレビューや経験、テストだけだとちょっと漏れることがあります。AWSだとConfigやTrusted Advisor、Google CloudであればRecommenderとか、そういったもので「こういう設定になってるけど大丈夫ですか」みたいなことを表示してくれたり警告してくれたりするサービスがあるので、そういったものをの使うのがいいかなと思います。

事故を防止する工夫

事故の防止、環境間違いの防止で、「開発環境を触っていたと思ってたけど、本番だった」みたいな。事故としてあると思いますが、例えばSSHで入った時の表示されるものを変えるとか。AWSやGoogle Cloudで環境ごとにアカウント変えたり、あとはChromeの拡張で、その時入ってるアカウントやプロジェクトによってバーの色変えたりがあるので、それ使ったり。

あとはちょっと不恰好かもしれませんが、リソースの名前の先頭のところにステージ名を入れてしまう。ちょっと泥臭いですが、見間違えることがないように何段階かこの事故の防止をするのもいいかなと思っています。

選定理由を残しておくことも大切

選定理由を残しておく。「なぜそのサービスか、こういうアーキテクチャにしたか」という理由を残しておいたほうがいいかと思います。それはWikiに残したり、アーキテクチャの図にコメントで書いておいたり、メインのシート以外に検討した結果をWebシートで残しておくとか。

そのあたりは忘れちゃう時があるのと、細かいことや考えてることをとりあえず吐いておきたいという場合は、Slackのパブリックの独り言チャンネルに垂れ流しておくと、あとでキーワードで検索して「あの時こんなこと考えてたんだな」というのがわかるので、僕はこれをやったりしています。

自分が使ったことないサービスでも「これってどんなだろう？」というのを社内のSlackで検索すると、けっこうドキュメントに書いてないような生々しいこと書いてあったら「こういうとこ気をつけなきゃいけないな」みたいに役立つこともあるので、やる時はパブリックのほうがいいかなと思っています。それで僕は助かったことがあるので、僕がそういったものの一部になれたらなと思って書いたり。主に自分のためですが、やっています。

やはりこういうことを残しておくと、「なんでこんなことになってるんだろう」と見直しをかける時や、似たようなこと考える時に役立つ。あとはいろいろな制限とか、「こういった理由でこういう判断をした」という、こういう理由の部分がアップデートで緩和されたり撤廃されることがあって、後から見ると「なんでやろ」みたいなものも「この時はそういう制限があったから」というものがあると、不安なく変更できるのでいいかなと思います。

EOLやアップデート追従の管理

次、EOLやアップデート追従の管理。AWSやGoogle Cloudとか、あとはSaaSとか、いろいろなもの使いますが、そういったものってすごい速度で進化していて。その恩恵を受けてはいますが、古いものが使えなくなったり推奨されなくなったりはあるので仕方ないかなと思いますが、ものによってはすぐ対応できないものもあるので、ある程度管理しないとなと思い、一応管理してみています。

これも今ちょっと泥臭い方法でやっていて。スプレッドシートにAWSやGoogle CloudやSaaSとか書いて、「何月にこれが非推奨になるよ」「何月にこれが廃止されるよ」みたいな。対象になりそうなサービスは、「僕たちが作ってるシステムでこれに影響がありそう」みたいなことを月1回見て、ちゃんとタスクになってるかとか、「そうそうこれは考えないといけないな」という、わりと泥臭い方法でやってます。「いや、こういう方法あるよ」とかがあれば、ぜひ教えてもらえるとすごく助かります。

覚えることもたくさんあるがアウトプットも大切

終わりにというところで、メンバーを募集していますということで。MSP開発というセクションで、運用業務の自動化・効率化を実現するシステムの開発をやっているので、興味がある方はぜひカジュアル面談などでお話しできたらと思います。

僕の部署以外にも、それぞれ条件は違うと思いますが募集してるので、検索してみてもらえればと思います。

あとAWSやGoogle Cloudの両方を使っていて、覚えることもいっぱいありますが、いろいろインプットしてアウトプットすると、自分で表現しようとして頭の整理になるのでいいなと思っていろいろやってみていて。

その中で最近いいなと思ったのが、こうやって登壇することもいいと思うんですが、手軽なのは勉強会のブログ、アウトプット枠みたいなもので、一般参加と別枠の枠があるものがあるんですけれど。参加してとりあえずブログを書く責務が与えられるので、なんか普通に参加するより真剣に聞くし、何かしらアウトプットするので気軽でいいかなと思います。

僕は土曜日とかにやってるイベントに参加するのが好きで。やはり平日だとちょっとソワソワするというか、自分のタスクや仕事がしたいなとあまり集中できないことがありますが、土曜日とかであれば昼ぐらいに起きて、（セッションを）聞いて、ちょっとブログにまとめて。プラスアルファで自分で調べたことも一緒に書いてとかすると、ログが1個できあがるのでいいかなと思っています。という感じで、ご静聴ありがとうございました。