00:10
はい、みなさんこんにちは。 keethこと桑原です。本日もやっていきましょう。 keethのエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することや、エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
本日はですけども、昨日言った通りなんですけど、ディベロッパーロードマップを眺めていて、一昨日にリアクトのロードマップを見て、昨日は何かのベストプラクティスを見てましたね。
いつの間にかですね、ロードマップの中にベストプラクティスというものが生えてまして、それを見ていたんですね。
昨日はフロントエンドパフォーマンスのベストプラクティスを見てました。今日はそのまま、AWSのベストプラクティスを眺めてみたいかなと思います。
他にもですね、APIセキュリティとかコードレビューとかもあって、これも気になりましてですね、全部見たくて仕方ないんですけど。はい、じゃあ行きましょう。
AWSのベストプラクティスですね。 ベストプラクティスはロードマップと違って、この4段階に分けているというわけではなかったりしますので、
カテゴライズというのは全然違うものになりますね。 今回はリファレンスとかリソーシーズを見てまして、
AWS Chips by Rich Adamsという方のAWS Chipsというものと、あとAWSオープンガイドですね。
これ多分公式のガイドかなっていうところの、この2つを一応リファレンスとかリソースにしてますよっていう話でした。
では早速入っていきたいと思います。ベストプラクティス1つ目に合わせディベロップメントですね。
開発におけるものなんですけど、Do Not Store Application State on Serversって言ってますね。
アプリケーションのステート状態っていうのをサーバー上にストアするなよって言ってますね。 これがまず1つ目でした。
で次が、Store Extra Information in Your Logsですね。 ログですねっていうのを、エクスナーで外部的なところに保管をしろと言ってますね。
続いて、If You Need to Interact with AWS, Use the Official SDKと。 もしAWSに興味があるんだったら、オフィシャルのSDKっていうのを使ってくださいよと。
まあそりゃそうですよね。SDKあるんだったら、それに乗っかって開発するのが多分一番いいと思いますし、
AWSの中の方が開発用にSDK整えてくださってるはずなんで、 もろもろの設定だったりとか準備とか、
いろんなことを吉成りやってくれてるものがあるんで、 それはSDKに乗っかった方が多分いいよねとは思います。
慣れてきたり、拡張したりとか独自なことをやりたいときに外れてるというか、 自分たちの路線でいけばいいって感じですね。
はい、じゃあディベロップメント4つ目、ラストですね。
Hub Tools to View Application Logsと。 アプリケーションログを見るためのツールっていうものを持ってくださいねってことですね。
しかもこれHubから始まったのでメール系ですね。 強く言われてます。
ロギングするのは当然なんですけど、そのログの可視化ってところもしっかりやりましょうねっていうお話でした。
なるほどですね。以上、ディベロップメント4つでしたね。
はい、じゃあ続いてビリング、お金回りのところですかね。
セットアップグラニュラルビリングアラートということで、 お金回りのところのちゃんとアラートをしっかり設定しましょうと。
結構そのお金回りのところで設定ミスったりとかいろんなことであって、 多大な請求が来てしまいまして、高くか。
03:04
で、公式の方に問い合わせをして泣き寝利用するみたいなのが結構あったりしますし、 権限回りとかですね。
設定とかも結構大事ですけど、お金って本当に大事になってくるので、 アラートはしっかり設定しておきましょうねってことでした。
じゃあ続いて、左回りで行こうかなこのまま。 左まで行くと、続いてはセキュリティですね。
セキュリティ一つ目ですけども、プリファEC2ロールズオーバーアップレベル IMアカウントと言ってますね。
IMアカウントを設定するのはそりゃそうですし、 EC2のロールの話の設定を推奨されてますと。
まあまあなんかその通りだよねって感じがしますね。
そもそもAWSのコンソールに久しぶりにログインしてないので、 久しぶりに入ってみたくなりますね、こういうのを見ると。
とりあえずアプリレベルのIMアカウントよりも EC2のロールっていうのを優先しましょうとか設定しましょうってことですね。
続いて、アサイン・パーミッション・トゥ・グループス、 ノット・ユーザーズと言ってます。
パーミッションですね、権限はユーザー、個々に設定するんではなくて、 グループに設定をしましょうと言ってます。
はい、じゃあ続いて3つ目。
セットアップ・オートメディット・セキュリティー・オーディティングとですね、
はい、セキュリティーの自動的な検知だったりチェックみたいなところですね、 もしくはオーディッツなので変更みたいなところまで行くのかな?
を自動化しましょうというお話ですね。
これもそうですね、人がやるよりは自動でやれるんだったらやった方がいいと思いますし、 セキュリティパッチっていうのが当たったらそれは自動的に入った方がいいと思うので、
その通りだと思いましたね。
はい、まあ一応でも内容をちゃんと見て設定を入れるかどうかっていうのは 本当はした方がいいと思ったりはします。
それによってアプリケーションが動かなくなったりすると結構めんどくさいのでね。
まあとはいえ、でもセキュリティーなんかインシデント起きた方が怖いので、
まあ自動化する方が良いかもしれないですね。
では続いて4つ目。
ユーズ・クラウド・トレイル・トゥ・キープ・アン・オーディット・ログと。
クラウド・トレイル僕はちょっと知らなくてアレなんですけど、
はい、クラウド・トレイルを使ってオーディットですね、ログ、まあ監査って英語、英訳されてましたけど、監査ログというのを残しましょうと言ってますね。
クラウド・トレイルはそういうものなんですけど、トレイルしてくれるんでしょうね。
で、以上セキュリティー4つってところでしたね。
IAMアカウントとかをよりもAC2のロールを捨てちゃいとか権限回りだったりとか、セキュリティーの自動化だったりとか、ログちゃんと残し続けましょうみたいな、そういうお話ですね。
では続いて、次はELBですね。ロードバランサーの話。
はい、ここは2つですね。
1つ目はTerminate SSL on the Road Balancerと言ってます。
ロードバランサーのSSLをやめましょうと言ってますね。
あ、そうなんですね。
理由とかが僕はちょっとあんまり詳しくないのとは、あんまりクラウド・インフラに詳しくないですけど、あ、そうなんですね。
SSLをロードバランサー上ではやめましょうと言ってますね。
では続いて、Pre-warm your ELBs if you are expecting heavy trafficと言ってます。
まあ、トラフィックが大きくなったり重くなってきた場合ですね。
ELBのPre-warmをしてくださいと。
まあ、でもこれはその通りだと思いますね。
では続いて、ELBは終了でRDSですね。
RDS1個しかないですね。
Setup Event Subscriptions for Failoverと言ってますね。
フェールオーバーした時のためにちゃんとイベントのサブスクリプション、検知というか監視的なところですね。
っていうのを、公読って訳すとちょっと難しいので監視に近い方がいいと思いますけど、っていうのをセットアップしましょう。
06:03
RDSはデータベースの話なので、フェールオーバーした時の検知は確かにした方が絶対にいいと思いますので。
これはベストというかもうマストです。
で、お次はクラウドウォッチですね。
クラウドウォッチは4つあります。
1つ目、Use CLI Toolsと言ってます。
これもその通りだなって感じですね。
CLI使ってくださいねっていう。
特に開発者であればもうまさにそうだと思います。
で、2つ目、Use the Free Metricsと。
フリーのメトリクスを使ってくれと言ってますね。
で、3つ目はUse the Custom Metricsと。
ちゃんと自分たちでメトリクス、何をメトリクスするかっていうところの設定だったりとか、項目っていうのをちゃんとカスタムしましょうねってことですね。
はい、でラスト。
Use Detailでモニタリングですね。
モニタリングですね。詳細モニタリングをしっかりやりましょうという感じですけど、
モニタリングだけで言うと、最近はいろんなサースがありまして、
クラウドウォッチでもいいんですけど、ちょっと見づらいとか、痒いところに手が届かないみたいな話をちょいちょい聞いたことがあってですね。
僕も多少見たことあるんですけど、確かに見やすいかって言われるとどうなんだろうって気はしてますので、
モニタリングとして、Datadogを使うとか、New Relicを使うとか、その辺の別のモニタリングサービスいっぱいありますので、その辺を使うほうが良いかもしれないですね。
自作するよりはそういうのを使った方がいいと思いますけど、
ただお金がかかったりするので、トレードオフだなっていう感じはしますけど、
とにかくモニタリングでも絶対やりましょうってことですね。
以上、クラウドウォッチ4つでした。
続いて、IAMですね。
IAM3つありますけど、1つ目はもうなんか笑っちゃいますけど、
Use IAM Rolesと言ってます。
はい、まあ、使えと。
まあ、これも議論の余地はないですし、説明の余地もないと思います。
続いて、Use Multiple API Keys for Different Purposes。
複数のAPIキーっていうのを異なる目的で使いましょうと言ってますね。
まあ、キーの使い回しをするなっていう意味かな。
こらさんもその通りだと思いまして、
1つ1つのキーに対して意味目的が1つでしょって思ってるので、
目的に応じてAPIキーを使いましょうってことですかね。
では続いて、Use Multifactor Auth for IAM Users。
マルチファクターはまあそうですよね、今は。
まあ、二要素認証もそうですし、まあ多要素認証と言ったりもしますけど、
を使うのはなんか今一般的ですからね。
まあ、認証周りとかは、パスキーが最近どんどんいろんなサービスとかが対応し始めたんで、
パスキーどうなんだろうなって気になってますし、
パスキーを使えるようになった方がいいとは思ったりはしますね。
特に管理権限周りとかになると、そこをクラッキングされたらことですからね。
まあまあでもとりあえずIAMユーザーの話ではあるので、
ちょっとそんなでかいとこじゃないにしても、
まあIAMユーザーに関してもなるべくマルチファクターオースを使いましょうって言ってます。
以上。で、続いて、Miscellaneous。
その他。その他ってそんな英単語なんですね。
Othersとかじゃなくて、Miscellaneousって言うんですね。
ちょっと発音がわかんなくてごめんなさい。
Miscellaneous。
はい、まあその他っていうところでざーっと見ていきますと。
一つ目はスケール・コリゾンタリーというので水平的にスケールしましょうでっていう感じですね。
まあ冗長化っていう話だと思いますけど、
まあスケールの話ですね。
水平方向へのスケールはちゃんと考えましょうねって話ですね。
それで二つ目。
Your application may require changes to work on AWS.
09:00
はい、AWSでちゃんと動くように必要があればアプリケーションの変更をしっかり適宜やってくださいねってことですね。
はい、では続いて。
Always be redundant across availability zonesって言ってますね。
Always be redundant across availability…
あーだからAvailabilityってAZの周りでなるべく冗長化をしてくださいってことですね。
AZはまた入れってことかな。
なるべく冗長化をしましょうというところですね。
はい、では続いて。
Be aware of AWS service limits before you deployですね。
はい、デプロイ前にサーバーの限界とかですね。
許容量みたいないろんなもののリミットっていうのをしっかり気にしましょうと言いますね。
はい、で続いて。
Decide on naming conversation early and stick to itって言ってますね。
Naming conversation early、ネーミングの会話早めに決めましょうと言ってますね。
はい、stick to itですね。
早く決めて早く守りましょうと言ってますね。
スティックって守るって意味があるんですね。
はい、では続いて。
Decide on key management strategy from the startですね。
開始する前にカギのマネジメントの戦略とか方針ですねっていうのをしっかり決めましょうと言ってますね。
カギの管理が本当に肝になりますからね。
はい、でラスト。
Make sure AWS is right for your workloadと言ってます。
AWSがワークロードに適しているかどうかを確認するかっていうのが一応その他の項目でした。
すいません、一旦ここでブツッと切って明日この続きをやっていきたいと思います。
明日は右の項目、AWSのベストアクラクティスで。
オペレーション S3 EC2 VPC Elastic Cache
オートスケーリング Root53とエラスティックマップリデュースですね。
はい、のお話に入っていきたいと思います。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。
