【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~コスト最適化~

はじめに

コスト最適化の柱は、パフォーマンス効率の柱と信頼性の柱との間で、トレードオフの関係にあります。
これは導入の稿でも触れたとおりです。

具体的には、下記のような問いを通して、各種要件の優先順位を決定していきます。
・市場投入までのスピードを重要視する?
・コスト最適化されたアーキテクチャを練るための時間を割ける?
・万が一を想定して多めにリソースを投資したほうが良い?

ホワイトペーパーでは、
・初期コスト最適化の方法
・継続的コスト最適化の方法
についてのガイダンスが提供されています。

設計原則とベストプラクティス

まず、設計原則と概要を見てみましょう。

次はベストプラクティスと、それに紐づくチェック項目。

最後に各ベストプラクティスの概要です。

候補サービス一覧

この柱のベースとなるサービスは、Cost Explorerです。
加えて、CloudWatchやTrusted Advisorで費用の経時変化を可視化し、各種コスト効率の高いマネージドサービスを利用します。パフォーマンス効率の柱と同様、最新情報のトラッキングが重要になっています。
一覧表にまとめてみましょう。

さいごに

Well-Architectedフレームワークのホワイトペーパーの概要、本稿まで6回に分けてご紹介しました。
このフレームワークは、クラウドに限らず、システム開発プロジェクトや組織運用などにも活用できる、きわめて汎用的な思考フレームだと思います。
どんな観点で全体を最適化するか、どこをゴールに設定し、どのようにカイゼンしていくか。悩んだ際はぜひご活用を!

参考リンク

オフィシャル W-Aホワイトペーパー


【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~パフォーマンス効率~

はじめに

AWSのアーキテクチャのパフォーマンス効率を上げるためには、どのような点に留意すればよいでしょうか?ホワイトペーパーから抜粋、まとめてみます。

設計原則とベストプラクティス

まず、設計の原則と概要です。

次はベストプラクティスと紐づくチェック項目。

最後に各ベストプラクティスの概要です。

候補サービス一覧

この柱のベースとなるサービスは、CloudWatchです。
トレードオフも選択に包括されると考えると、下記のような流れで設計していくことになります。
●要件に応じて最適なサービスを選択、アーキテクチャを構築
●CloudWatchで全体的なパフォーマンスと運用状態を可視化
●もっと良いソリューションがないか、AWSブログなどで情報取得
昨今注目されているマイクロサービスには、下記を活用します。
●Elastic Kubernetes Service(EKS) (コンテナサービス)
●Lambda (サーバレスアーキテクチャの基軸)
他のマネージドサービスも入れて、一覧表にします。

まとめ

パフォーマンス効率を維持するうえで留意しなくてはいけないポイントと、活用するサービスの概要、つかめましたでしょうか?次回は最後の柱、コスト最適化についてお送りします!

参考リンク

オフィシャル W-Aホワイトペーパー


【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~信頼性~

はじめに

クラウドならではの強みである自動化をうまく活用・管理することで、より信頼性の高いアーキテクチャを設計することができます。

設計原則とベストプラクティス
設計原則と、ベストプラクティスに紐づくチェック項目を見てみましょう。

管理やモニタリングなど、セキュリティの柱と共通する文言が並びます。セキュリティが高い状態でないと、信頼性の高いアーキテクチャは設計できないませんね。ベストプラクティスの概要を抜き出してみます。

候補サービス一覧

この柱のベースとなるサービスは、CloudWatchです。
下記のような構成が基本となります。
●IAMを中心にセキュリティに守られた基盤を構築
●CloudWatchなどで変更ログをトラッキング
●Auto Scalingで必要に応じてリソースをスケール
●障害が起こった時のためにCloudFormationでテンプレを作成、ストレージにバックアップ
他のマネージドサービスも入れて、一覧表にしてみます。

まとめ

信頼性の高いアーキテクチャを設計するうえで留意しなくてはいけないポイントと、活用するサービスの概要、つかめましたでしょうか?次回はパフォーマンス効率の柱についてお送りします!

参考リンク

オフィシャル W-Aホワイトペーパー


【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~セキュリティ~

はじめに

クラウドで第一に考えなくてはいけないのが、セキュリティです。インシデントの予防策だけではなく善後策を考慮して設計します。

設計原則とベストプラクティス

設計の原則と、ベストプラクティスに紐づくチェック項目を見てみましょう。

セキュリティ維持のためには、細目にわたって設計する必要がありそうです。
各ベストプラクティスの概要を抜き出してみましょう。

つまり、
●アクセス元からデータ保存先に至るまでのそれぞれのレイヤーでセキュリティを担保し、
●万が一、問題が起こった場合でもいち早く原因を特定できる状態にしておき、
●有事の際でも、すばやく再びセキュリティが担保された状態に戻せるようにする
ということになります。

候補サービス一覧

この柱のベースとなるサービスは、Identity and Access Management (IAM)です。
下記のような構成が基本となります。
●IAMで最小権限の法則にのっとってアクセス管理を行う
●インフラや各種データが守られるように設定する
●仮にインシデントが発生してもCloudTrail、CloudWatchで把握できるようにしておく
他のマネージドサービスも入れて、一覧表にしてみます。

まとめ

セキュリティを高めるうえで留意しなくてはいけないポイントと、活用するサービスの概要、つかめましたでしょうか?次回は信頼性の柱についてお送りします!

参考リンク

オフィシャル W-Aホワイトペーパー


【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~運用上の優秀性~

はじめに

運用上の優秀性が高い状態、細かいことをざっくり省いて一言でいうと、
システムを継続的に改善できる状態
になろうかと思います。
継続的にというのがキーです。
お客さんの要望を反映する形で、日々便利なサービスが登場しています。これらを積極的にアーキテクチャに反映させることで、より優秀な運用ができるようになります。

設計の原則

ではこの柱の設計原則を見てみましょう。

ベストプラクティスとチェック項目

原則だけだと具体的にどんなポイントに留意すべきか、なかなかつかめませんね。ベストプラクティスとチェック項目を見てみましょう。

ではどのような作業を行う必要があるでしょう?
各ベストプラクティスの概要を抜き出してみます。

流れだけ抽出すると、
●しっかり準備をすれば運用が簡単になる、
●簡単になればどこをどう変えればもっといい運用方法になるか見つけやすい、
●見つけられればアーキテクチャを進化させられる、
という感じでしょうか。

候補サービス一覧

具体的にどのようなサービスを活用すればよいのか、一覧表にまとめます。
CloudFormationを軸に、CloudWatchやCloudTrailなどを組み合わせて活用していく形です。

まとめ

運用上の優秀性を高めるうえで留意しなくてはいけないポイントと、活用するサービスの概要、つかめましたでしょうか?次回はセキュリティの柱についてお送りします!

参考リンク

オフィシャル W-Aホワイトペーパー


AWS CloudFormation Master Class を受けてみた⑥「Conditions・Metadata・Init について」

はじめに

Udemy にて Stephane Maarek 氏 が提供している「 AWS CloudFormation Master Class 」コースについて紹介していきます。今回の内容は、「 CloudFormation Resources 」と「 Mappings 」についてです。
これまでの AWS CloudFormation Master Class の記事
その①「 CloudFormation について 」
その②「 CFnを利用したS3環境の構築 」
その③「 CloudFormation Designer でテンプレートの作成 」
その④「 Parameters について 」
その⑤「 Resources と Mappings について 」

Conditionals

Conditionals とは


Conditionals は、condition を元に作成されたリソースやアウトプットの構築をコントールすることができます。そして、condition は他の condition やパラメータに影響を与えることができます。
主な Conditions として以下があります。
・構築環境(開発/検証/本番 など)
・AWS リージョン
・パラメータ値

図のように、Logical ID は、Condition のことを表しており、そして Intrinsic function は以下のように表します。
●Fn::And
●Fn::Equals
●Fn::If
●Fn::Not
●Fn::Or

Hands-On

ダウンロードしたファイルの中にある [0-mappings-ec2.yaml] を開いて、Conditons のコードを見てみましょう。

ここに書かれている内容から、以下のことが分かります。
●Conditions は「CreateProdResources」である
●「CreateProdResources」は「EnvType」が「prod」の場合のみ、「true」であることを表している

この図の内容から、以下のことが分かります。
●EC2 は特に Condition が設定されてないので、設定通りに作成される
●Condition は 「CreateProdResources」である
●「true」の場合にのみ 「MountPoint」、「NewPoint」、「Outputs」の3つが作成される

Conditions Functions


以下の5つの条件関数は、CloudFormation でコードを書く際にとてもお世話になるので、この5つについては把握しておきましょう。
条件関数については、AWSの公式より詳しく記載されてますので、こちらも参照下さい。
●Fn::And
指定された全ての条件が「true」の場合「true」を返す(それ以外は「false」)
●Fn::Equals
指定した2つの値が同じ場合「true」を返す(それ以外は「false」)
●Fn::If
指定された条件が「ture」・「false」に評価された場合、それぞれに対応する値を返す
●Fn::Not
false と評価された条件に対して「true」を返す(その逆に対しては「false」を返す)
●Fn::Or
指定された条件のいずれかが「true」に評価された場合「true」を返す(条件が全て「false」と評価された場合は「false」)
また、これ以外で重要なのものとして、「Fn::GetAtt」があります。
●Fn::GetAtt
テンプレートのリソースから、属性の値を取得する

CloudFormation Metadata

Metadata

Metadata というセクションを使うことで、リソースやテンプレートに対して、それぞれの詳細を加えることができます。

以下の3つの Metadata key はとても重要なので見ておきましょう。
●AWS::CloudFormation::Designer
テンプレート上のリソースがどうレイアウトされているかを記述し、AWS Designer で自動的に追加される
●AWS::CloudFormation::Interface
インプットパラメータが AWS Console に表示された際にグループ化とソート化をする
●AWS::CloudFormation::Init
cfn-initの構成タスクを定義している

AWS::CloudFormation::Init

上記の3つの Metadata key の中でもとりわけ重要な AWS::CloudFormation::Init について説明します。

AWS::CloudFormation::Init の中には Config が用意されており、以下の内容が順番に書かれております。
●Packages
Linux OS 上のパッケージリストをインストールする
●Groups
ユーザグループを判別する
●Users
ユーザと、その所属グループを判別する
●Sources
アーカイブファイルをダウンロードし、EC2インスタンスに置く
●Files
EC2インスタンス上にファイルを作成する
●Commands
コマンドを実行する
●Services
sysvinit サービスを起動する

AWS::CloudFormation::Init の特徴についてまとめると、以下となります。
●AWS::CloudFormation::Init の中に複数の config を用意することができる
●複数の config から configset を作成することが可能
●EC2 ユーザのデータから、config セットを呼び出し可能

Packages


Packages の特徴は以下となります。
●package は、apt、msi、python などのリポジトリからインストールが可能
●package は rpm、yum/apt、rubygems、python の順番で作成される
●package はバージョンの指定も可能

Groups and Users


●CloudFormation Init Metadata に groups と users を入力することで、複数のグループとユーザの登録が可能
●特定のグループを指定すといった設定も可能
●ユーザの所属グループの指定や、ユーザの指定といった設定も可能

Sources


●web からアーカイブを直接ダウンロードして、インスタンスに入れることが可能
●URL があれば、S3 や github からでも取ってくることが可能

Files


●全てのコンテンツに対してフル権限と操作が可能
●インラインや URL での指定も可能

Function Fn::Sub


●テキストに入力された変数の代わりになることが可能
●テンプレートのフルカスタマイズが可能
●AWS 疑似変数などと組み合わせることが可能

Commands


■アルファベット順にコマンドを1つずつ実行可能
■環境変数や作業ディレクトリの設定も可能

Services


●インスタンス起動時に紐付いているサービスを起動可能
●ファイルの変更やパッケージのアップデートがされた際、cfn-init による再起動の確保が可能

Cloudformation ヘルパースクリプトリファレンス

CloudFormation には、スタックの一部として作成する EC2 インスタンスでソフトウェアをインストールしたり、サービスを開始したりするために使用できる Python ヘルパースクリプトが用意されております。そのいくつかを紹介していきます。

cfn-signal


cfn-signal の特徴は以下となります。
●cfn-signal は、リソースの構築が無事に完了したことを CloudFormation に伝える為に利用する
●cfn-signal は、CreationPolicy と共に使用される
図の例の内容は、インスタンスが自動構築されてオンライン上に出るまでのタイムアウトは、最大5分の設定であることが分かります。もし5分経っても cfn-signal から通知が来ない場合は、CloudFormation はロールバックを行います。

cfn-hup


cfn-hup の特徴は以下となります。
●cfn-hup は EC2 インスタンスに対して、 Metadata の変更点を15分毎に監視し、変更があれば再構成を行うよう指示することが可能

おわりに

Conditions・Metadata・Init についての説明は以上となります。今回紹介した機能を使って、CloudFormation をより便利に活用していきましょう。


AWS CloudFormation Master Class を受けてみた③ 「 CloudFormation Designer でテンプレートの作成 」

はじめに

引き続き、Udemy にて Stephane Maarek 氏 が提供している「 AWS CloudFormation Master Class 」コースについて紹介していきます。今回は、CLoudFormation Desinger の機能とその使い方についてです。
これまでの記事
AWS CloudFormation Master Class を受けてみた①
AWS CloudFormation Master Class を受けてみた② 「 CFnを利用したS3環境の構築 」

Using CloudFormation Designer


CloudFormation では、テンプレートをデザインすることができます。
それにより、テンプレートの内容を可視化しながら作成できます。

テンプレートのデザイン①


CloudFormation のサービス画面から、左上の「テンプレートのデザイン」を選択します。

テンプレートを作成したいサービスを、左の一覧から選択したら、あとは右側に持ってくるだけです。
ここでは、EC2 インスタンスを例に行っています。
これで、EC2 インスタンスのテンプレートは完了しました。

テンプレートのデザイン②

次に、作成した EC2 インスタンスに対して固定 IP を設定してみましょう。

これで固定 IP の設定も完了です。
セキュリティグループの設定も、同じ様に行うことができます。

他にも、既存の YAML テンプレを貼り付けることで、YAML の内容を図で確認することができます。


デザインしたテンプレートを使用する際は、左上のアイコンより「アップロード」をクリックします。

テンプレートの選択画面で、「 Amazon S3 テンプレート URL の指定 」に、アップロードしたテンプレートの URL が表示されていることを確認したら、「 次へ 」を押して作成すれば完了です。

まとめ

CloudFormation のテンプレートをデプロイする方法は2通りあります。

■手動でデプロイ
・CloudFormation Designer でテンプレートを作成
・コンソールからパラメータを入力
■自動でデプロイ
・YAML ファイルでテンプレートを編集
・AWS CLI を使用してテンプレートをデプロイ

おわりに

CloudFormation Designer でのテンプレートの作成の紹介については以上です。
このサービスを利用することで、ユーザ自身でテンプレートを自由にデザインし、デプロイすることができます。
次回は、CloudFormation のparameter について紹介していきたいと思います。


【AWS】Well-Architected Frameworkをホワイトペーパーから紐解く ~導入編~

はじめに

Well-Architectedフレームワーク ホワイトペーパー、皆さんご覧になったことはありますでしょうか?AWSのソリューションアーキテクトになるのであれば、一度は目を通しておきましょう、というアレです。
ただ、私にとっては、
・オンプレでのインフラ構築/運用経験がないので、情報量が多く、オーバーフローぎみ
・フレームワークの重要性は、ウェビナーでも多く触れられてるけど、いまいちその理由が腑に落ちない

だったので、ホワイトペーパーを参考にしつつ、自分が理解しやすいように整理してみようと思います。
今回は導入部として、

・ソリューションアーキテクト = 建築家
・クラウドでの一般的な設計原則
・要件のトレードオフ
という観点で書いてみます。

ソリューションアーキテクト = 建築家

AWSソリューションアーキテクト。
建築家というからには、施主の立場で考えるのが良さそう、ということで例をあげます。

依頼者目線で

あなたは家を建てたいとしましょう。
そんな時、きっとこんなことを考えます。
・部屋は何部屋欲しい?
・家族は何人? 将来家族が増えた場合も考える?
・災害が起こった場合はどうする?
・何年くらい住む?
・予算は?
悩んだ末、要件が固まってきました。
誰かに設計を依頼することにします。
図面の引き方を知っていて、建材について知っている、それだけの建築家は避けたいですね。
やっぱり経験豊富な人にお願いしたいところです。

建築家との共通点

AWSソリューションアーキテクトと建築家、共通する点があるはず。
それぞれ何をする人なのかざっくり書いてみましょう。

設計対象と必要な知識は違いますが、
要件の優先順位をクライアントと一緒に洗い出し、
物事の基盤を設計する
という点で、本質的に通底しているように思います。

ASA試験の設問意図

ASA試験の受講レベルの目安の一つに、実務経験の長さがあります。
難しい試験になるほど、
要件の全体像を把握したうえで、
顧客とっての価値を最大化する
ようなアーキテクチャを選択させるような設問が多く出題されます。
いわば、建築家としての総合力が試される形ですね。非常に合理的。
AWSが蓄積している優れた建築家のノウハウの集合体がWell-Architectedフレームワークです。

クラウドでの一般的な設計の原則

さて、クラウドを利用するなら、その利点をしっかりと認識しておくべきです。
クラウドの一般的な設計原則を見てみましょう。

要件のトレードオフ

要件のすべて満たすアーキテクチャ設計は困難です。
例えば、サーバーを助長化することで信頼性を上げることはできるけど、それでは予算オーバー、というような場合。
よって、要件のトレードオフが必要になってきます。
トレードオフをするためには、要件の優先順位をつけなくてはいけません。
フレームワーク各柱の間の関係性は下図の通り。

信頼性、パフォーマンス効率、コスト最適化は三すくみの関係になります。
セキュリティと運用上の優秀性は、通常はトレードオフになることはないそうです。

おわりに

次回からはフレームワークの柱、それぞれについて、ホワイトペーパーからtipsをお届けします!

参考リンク
オフィシャル W-Aホワイトペーパー


AWS Deep Racer League 参加レポート

はじめに

今回は AWS Summit Tokyo2019 にて開催された AWS Deep Racer League に参加したので、その結果を記録します。

AWS Deep Racer とは

強化学習で作成したモデルによって走る、1/18 スケールの 4WD モンスタートラックです。
3D レーシングオンラインシミュレーター上で強化学習によるモデルを作成し、モデルを Deep Racer にデプロイして、コースを走らせることができます。
AWS DeepRacer では、あらゆるレベルの開発者が強化学習を開始できるよう、ハンズオンチュートリアルを用意されているため、強化学習初心者でも簡単に強化学習を楽しめます。

AWS Deep Racer League とは

誰でも参加できる、Deep Racer によるレーシングリーグです。
仮想サーキットによるオンラインレースと AWS Summit 会場にて行われる Summit サーキットの2種類があります。
今回私は Summit サーキットに参加してきました。

Deep Racer 会場

会場にはコースが2つ用意されていて、中央のモニターにはリアルタイムでランキングが表示されていました。

モデルを持っていなくても、AWSの用意したモデルを利用してレースに参加できるため、多くの人が列に並び、待ち時間は3時間まで伸びてました。

レース参加!

今回はモデルを持ち込みでレースに参加してきました。
結果は 10.610秒 で全体としては39位でした。
AWS Summit Tokyo の ランキング
https://d3akhm1epsal2g.cloudfront.net/bigscreen/?event=tokyo


シミュレーションでは12秒台だったので、やはりシミュレーションと実機では差がでますね。

最後に

今回はDeep Racer Leagueに参加したレポートを書きました。
会場の実機で走らせてみると、うまく走れたり走れなかったする様を見て、ついつい頑張れって声に出してしまうほど楽しめました。
オンラインレースは6月30日まで開催されているので、まだ機械学習触れたことない人でもぜひ、参加してみてください。


【AWS】MFA認証にMicrosoft Authenticatorを使う

MFA認証にMicrosoft Authenticator アプリを使用しているOffice 365ユーザーは多いと思います。
AWSでこれを使っている方が少ない印象だったので、手順を残しておきます。

用意する端末

・PC or MAC
・お手持ちのスマホ

手順

お手持ちのスマホにアプリをインストール

AWSにログイン、アカウント名のタブで、マイセキュリティ資格情報をクリック

MFAの有効化をクリック

仮想MFAデバイスを選択、続行をクリック。

QRコードの表示をクリック

スマホでQRコードリーダーを開く

PCに表示されたコードを読み取り、Authenticatorで開くをクリック

Amazon Web Serviceの項目が追加されます。カウントがゼロになる前にこの6桁の数字を...

PCのMFAコード1に入力

スマホに戻り、先ほど入力した数字のカウントが切れて、新しい数字になったら、この数字を...

今度はMFAコード2に入力し、

MFAの割り当てをクリック

この画面が出たらOK

さいごに

Well-Architectedフレームワークに関する記事でも触れたように、セキュリティの担保はクラウド利用時の最重要項目です。なかでもMFA認証の有効化は必須。皆さんもれなく設定しましょう。