継続は力なり

認証情報レポートとは
- レポートの項目
認証情報レポート生成方法
- AWS マネジメントコンソールから生成方法
まとめ

認証情報レポートとは

「認証情報レポート」とは IAM ユーザーの各種認証情報 (パスワード,アクセスキー,MFA デバイスなど) の設定状況をレポートとして出力してくれる機能です.レポートは4時間ごとに1回生成されているので,最新のレポートでは過去4時間以内のレポートを利用者は入手可能です.

レポートの項目

「認証情報レポート」の項目がどのようになっているかですが,次の項目があります.

カラム名	説明
user	ユーザー名
arn	IAMユーザーのARN
user_creation_time	ユーザーが作成された日時 (ISO 8601 日付/時刻形式)
password_enabled	ユーザーがパスワードを持っている場合`TRUE` それ以外の場合は`FALSE` AWS アカウントのルートユーザーは`not_supported`
password_last_used	ルートユーザーまたは IAM ユーザーのパスワードを使用して最後に AWS ウェブサイトにサインインした日時
password_last_changed	ユーザーのパスワードが最後に設定された日時ユーザーがパスワードを所有していない場合,`N/A (該当なし)` ルートユーザーは`not_supported`
password_next_rotation	パスワードの更新を必要とするパスワードポリシーがある場合,新しいパスワードを設定するためのユーザーに求める日時ルートユーザーは`not_supported`
mfa_active	MFA が有効な場合,`TRUE` 無効な場合,`FALSE`
access_key_1_active	ユーザーがアクセスキーを所有しアクセスキーのステータスが `Active`である場合`TRUE` それ以外の場合は`FALSE`
access_key_1_last_rotated	アクセスキーが作成または最後に変更された日時アクセスキーを所有していない場合`N/A`
access_key_1_last_used_date	AWS API リクエストにユーザーのアクセスキーが使用されたときの ISO 8601 日付/時刻形式の日付と時刻
access_key_1_last_used_region	アクセスキーが使用されたリージョン
access_key_1_last_used_service	アクセスキーを使用して最近アクセスされた AWS サービス
access_key_2_active	ユーザーが 2 つ目のアクセスキーを所有し,その 2 つ目のキーのステータスが`Active`である場合`TRUE` それ以外の場合`FALSE`
access_key_2_last_rotated	ユーザーの 2 つ目のアクセスキーが作成または最後に変更された日時
access_key_2_last_used_date	AWS API リクエストにユーザーの 2 つ目のアクセスキーが直近に使用されたときの ISO 8601 日付/時刻形式の日付と時刻
access_key_2_last_used_region	ユーザーの 2 つ目のアクセスキーが直近に使用されたリージョン
access_key_2_last_used_service	ユーザーの 2 つ目のアクセスキーを使用して最近アクセスされた AWS サービス
cert_1_active	ユーザーが X.509 署名証明書を所有しその証明書のステータスが`Active`である場合`TRUE` それ以外の場合`FALSE`
cert_1_last_rotated	ユーザーの署名証明書が作成または最後に変更された日時
cert_2_active	ユーザーが2つ目の X.509 署名証明書を所有しその証明書のステータスが`Active`である場合`TRUE` それ以外の場合`FALSE`
cert_2_last_rotated	ユーザーの2つ目の署名証明書が作成または最後に変更された日時

AWSドキュメント

認証情報レポート生成方法

前提として以下の権限がレポートの生成に必要です.

認証情報レポートを作成生成する : GenerateCredentialReport
レポートをダウンロードする : GetCredentialReport

AWS マネジメントコンソールから生成方法

マネジメントコンソールからの生成方法は以下の通りです.

1, IAMの画面より「認証情報レポート」を選択します.

f:id:sadayoshi_tada:20190918231623p:plain

2, 「レポートをダウンロード」を選択すると,「status_reports_YYYY-MM-DD THH-MM-DD+SS-SS(ISO 8601 日付/時刻形式).csv」ファイルがダウンロードされます.

f:id:sadayoshi_tada:20190918231659p:plain

まとめ

IAM の「認証情報レポート」の概要とレポートの項目,その生成方法をまとめました.IAM は AWS の権限管理の基盤となりますので,組織の運用方針に沿った管理ができているかを定期的に確認する材料として活かせるレポートです.運用で IAM ユーザーを棚卸する必要がある場合,「認証情報レポート」の利用を検討してみていかがでしょうか？

なお,レポートに関係するパスワードポリシーは IAM のメニューの「アカウント設定」より確認可能です.

AWS ドキュメント docs.aws.amazon.com

2019-09-15

東京リージョンの障害から設計と運用の考慮点を整理する

AWS

タダです.

先日, AWS の東京リージョンでの障害があったことは AWS 利用者のみなさんはご存知かと思います.今回の障害を踏まえ,今後の設計や運用にどう活かすかを考えたりチームで話し合ったりしていると思うのですが,僕も所属チームで振り返りをしました.その振り返りを踏まえ,自分なりに今回の障害から今後の設計と運用にどう活かしていくかをこの記事に残していきます.なお,記事で取り扱う考慮点以外にも考慮事項がある場合,ご指摘いただけるとありがたいです.

公式レポート

メディアの記事

www.itmedia.co.jp

piyolog さんの時系列や影響のあったサービスの記事

piyolog.hatenadiary.jp

AWS CLI で振り返る AWS 障害時の各種ステータス確認方法

設計の考慮点
運用の考慮点
まとめ

設計の考慮点

今回の障害を受けて設計時に検討が必要なキーフレーズとして以下を考えます.

Availability Zone の冗長化(マルチAZ)
ELBのスティッキーセッション
ステートレス
Design for Failure

Availability Zone の冗長化(マルチAZ)

AWS のネットワーク設計の重要な概念の1つである Availability Zone (データセンター群)を冗長化するのは今回のような特定の Availability Zone で障害が発生した時もシステムの稼働を継続させるために行います.

東京リージョンでは現状3つの Availability Zone が利用可能です.ただ,今回の障害においては冗長化した Availability Zone(マルチAZ) に設定していても影響があったサービスがありました.3つの Availability Zone において影響があったかは公開されてないものの,システムの可用性を上げるために利用可能な Availability Zone は全て利用した設計を検討すべきでしょう.当然ながら Availability Zone を冗長化していれば万事安全ではなく,後述する復旧の手順・プロセスや承認フローを確立しておくのも合わせて大事だと考えます.

個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。

ELBのスティッキーセッション

今回の障害でも影響があったとレポートがあったスティッキーセッションですが,チーム内の振り返りでスティッキーセッションはできる限り使わず,ステートレスな設計を進めるべきだと話し合いました.ステートレスの話は後述するためここではスティッキーセッションの話を整理しておきます.

ロードバランサーのスティッキーセッションの効果は,セッション維持を固定のインスタンスで管理することです.今回の障害では特定の Availability Zone 1つで障害が発生して該当の Availability Zone に配置したサーバーは稼働できない状況に陥りました.そのため,セッション管理の維持は可能であれば,例えばデータベースやキャッシュサーバーに外出し管理する設計をできないかを検討しましょう.

AWS ドキュメント

ステートレス

チーム内の振り返りでスティッキーセッションを使わず,ステートレスな設計を使って EC2 を AutoScaling で構成していた場合復旧はインスタンスを入れ替えるだけで復旧できた事例がありました.ステートレスな設計をしておくことで復旧が簡易かつ,迅速に行えたことはとても有益な設計考慮点だと言えるのではないしょうか？また,有名なThe Twelve-Factor Appにもステートレスが文脈に出てくるほどです.このような事実と設計思想からステートレスな設計が今後の設計で活かしていきたいと強く感じたポイントでした.改めてThe Twelve-Factor Appの思想も読み直します.

AWSでアプリ開発するなら知っておくべこと from Keisuke Nishitani

www.slideshare.net

Twelve-Factor App(日本語訳) 12factor.net

Design for Failure

クラウドと言えどもオンプレミスのデータセンター同様にサーバーがダウンしてしまうことはあるということを今回再認識された方は多いのではないでしょうか？障害が発生することを前提に設計する考えを Design for Failure(故障のための設計)と呼びますが,まさしくこの観点を入れる必要があります.この設計の考えを実現するには,如何に復旧する仕組みを入れるかがキモですが,自動復旧するように AutoScaling やAutoRecovery, CloudWatch Events などを取り入れて障害に強いアーキテクチャを検討しましょう.

Amazon EC2のイベント対応を楽にするためのアイデアと「Design for Failure」の考え方

codezine.jp

運用の考慮点

今回の障害を受けて運用で検討が必要なキーフレーズとして以下を考えます.

障害検知
バックアップの取得
復旧試験の実施
カオスエンジニアリング

障害検知

一般的にサーバーの監視は各種サービスを使って管理していいると思いますが,今回のようなサービス基盤の障害を感知する手段をここでは整理します.AWS にはAWS Personal Health Dashboardで通知を受取り,障害を感知することが可能なので, CloudWatch Events と組み合わせて設定しましょう.障害だけでなく, EC2 のリタイアメントのイベントも通知可能です.

AWS Personal Health Dashboard

CloudWatch Events との統合

バックアップの取得

障害に対峙するために改めて AMI やスナップショットを取得し,復旧できるようにする仕組み化できていない部分がないかを見直しましょう.管理している AWS 環境によっては大量のリソース状況を網羅するのは容易ではないため,AWS Trusted Advidosr を使って確認するのもよいでしょう.

AWS Trusted Advidosr のベストプラクティス

Effective DevOps ―4本柱による持続可能な組織文化の育て方

復旧試験の実施

バックアップを取るだけでなく,どう復旧するかの復旧プロセスや組織内で復旧を誰がどのようにハンドリングするかの方針を確立し,復旧プロセスの試験も行うべきでしょう.復旧できてこそバックアップの効果がでます.そのためにも,バックアップを使って如何に復旧するかを試験してリリースするのが望ましいと考えます.

カオスエンジニアリング

障害を意図的に起こして対応する手法として,カオスエンジニアリングがあります.Netflix で実際に行われている手法です.詳細はまた別の記事で整理したいと思いますが,カオスエンジニアリングの目的は本番サービスで意図的に障害が発生しても復旧し,通常サービスを提供していけるかといった安定性・可用性向上のためです.リリースできたから OK ではなく,システムを育て続けるための手法の1つとして検討して良いかもしれません.なお,日本ではクックパッドさんがカオスエンジニアリングの実施宣言をした記事が有名ですね.

PRINCIPLES OF CHAOS ENGINEERING

principlesofchaos.org

Chaos Engineering やっていく宣言

techlife.cookpad.com

まとめ

先日発生した AWS の Availability Zone 障害から今後の設計や運用に活かすための整理を行いました.クラウドといえどオンプレ同様にデータセンターで管理されているのだから障害は発生するし,障害が発生したからクラウドがダメでなく,クラウドの強みを活かすよう今回の経験を活かした改善活動に繋げたいですね.

2019-09-09

Effective DevOpsオンライン輪読会第15回開催レポートと振り返り

タダです.

challenge-every-month の Slack メンバーで「Effective DevOps」のオンライン輪読会を継続してきましたが今回が本書のラストの輪読会でした.

作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2018/03/24
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

開催概要

方針や輪読会の概要は @kojirock さんがまとめてくださっているのでご覧ください.

過去の開催レポート

これまでの開催レポートは以下の通りです.

kdnakt.hatenablog.com

kdnakt.hatenablog.com

担当章について

今回の範囲は18章から19章までになります.最終章となるためまとめの話が多くなっていました.

資料

資料はこちらです.

所感

個々人の意見を重視し、仕事よく知る人に改善方法を提案してもらうのがDevOpsで大きな成果の基礎になってる
- 個人を一作業員として軽視せず,業務をよく知るメンバーとして意見を尊重し,フェアに評価していく
組織の健全性は,人の受け入れ・昇進・退職・勤務形態の選択などに現れる
- 上記のような文化的課題を文化的負債といい,負債なので対処していかなければ組織の悪影響は広がり続けることになる
不健全なシステムや組織の観点が書かれており,自分の環境はどうなのかを見るための参考になった
DevOps とサイロ化の問題がよく文脈に出てきたが,いまいち理解できていなかったので整理してみた.
- サイロ化とは,システムや業務プロセスが他のアプリケーションや他事業部や部門との連携を持たずに自己完結して孤立してしまう状態
  - サイロ化は他チームとのコミュニケーションが取りづらい状況を作る(改善や課題が共有されづらい)
- DevOps は孤立したチームやコミュニケーションの取りづらい状況を改善し,組織のゴールは何で,どう実現するための文化を醸成していく活動になる
DevOps に万能なソリューションはなく,大事なのは組織における課題を明らかにして見分ける必要がある
- 最終目標は顧客のために問題を解決できる組織を作り維持すること
- DevOps には終わりはなく,継続的に繰り返し改善し続けていく反復的プロセスなので,旅と似ているなと思った

まとめ

第15回目の輪読会で扱った資料と所感を書きました. オンライン輪読会は継続するかをメンバー同士で話して,これまで通り輪読会を継続していくのが難しそうだったため一旦終了としました.振り返ると全員が直接面識ない中でも一冊の本を読破できたことはすごく嬉しいですし,その要因は何かなと振り返ったら3つのポイントがあったと思います.

全員自宅から参加したが,Slack,Skype を使って知見や考えを共有してコラボレーションできたこと
本書のような300P超えの本を各章で細かく区切り進めることで読書のペースを作れたこと
継続することに重きを置き,訳あってスキップしたいときは気軽にスキップできるようにしたこと

約四ヶ月完走できてよかった... @kojirock さん,kdnaktさん,参加いただきありがとうございました！また都合が合えばオンライン輪読会開催予定です！

2019-09-08

Amazon Forecast で家庭の電力消費量を予測する

AWS Amazon Forecast

タダです.

Amazon Forecast が一般利用可能になったので,サンプルデータを突っ込んで時系列データ予測を行ってみます.

Amazon Forecast の概要
サンプルデータをインポートして Amazon Forecast の時系列予測を行う
まとめ

Amazon Forecast の概要

Amazon Forecast は時系列予測のためのフルマネージドサービスです.過去の時系列データを提供することで時系列の未来を予測できます.例えば,小売・財務計画・サプライチェーン・ヘルスケアなど複数の分野で時系列予測は役立ちます.

AWSドキュメント docs.aws.amazon.com

そもそも時系列予測って何かというと,時間単位で整列したデータの集合です.

Q: 時系列データとは何ですか?

時系列とは、何らかの時間単位で整列されたデータポイントのセットです。時系列の例としては、ある商品の週間売上、日々の在庫状況、1 時間ごとのウェブサイトアクセス数などが挙げられます。

Amazon Forecast の仕組み

Amazon Forecast でデータの予測をするための仕組みとして以下の3つを理解しておきます.

データセットおよびデータセットグループ : Amazon Forecast で予測する対象のデータ.データセットグループを作成し,関連するデータセットを追加する.Amazon Forecast アルゴリズムはデータセットを利用して,予測子というカスタム予測モデルをトレーニングする.
予測子 : データに基づいて学習されたモデル.予測子をトレーニングするには,事前に構築されたアルゴリズムか,AutoML オプション(Amazon Forecast に最適なアルゴリズムを選択するよう依頼)を選択する.
予測 : 時系列データの予測を生成する.予測結果をS3 バケットにエクスポートする

対応リージョン

対応リージョンは,以下の通りです.

料金

料金は以下のようになります.

価格タイプ	価格
予測の生成	1,000個の予測あたり $0.60
ストレージ容量	GB あたり $0.088
学習時間	1時間あたり $0.24

サンプルデータをインポートして Amazon Forecast の時系列予測を行う

サンプルデータ(時系列の過去の電力使用量)をインポートして, Amazon Forecast の時系列予測を行います.なお,詳細な手順はドキュメント内に記載があるので,サンプルデータを Amazon Forecast にインポートして時系列予測を行うまでの注意点や理解したことをまとめます.

AWS ドキュメント

サンプルデータをインポートして時系列予測を行う手順 docs.aws.amazon.com

サンプルデータの準備方法 docs.aws.amazon.com

サンプルデータをインポート時の注意点

サンプルデータをデータセットに登録する際にデータスキーマというデータタイプと順序を時系列データ(インポートデータ)に一致するように更新する必要があります.サンプルデータはデータセットグループのタイプとしてCustomにあたるので,timestamp,target_value,item_idのカラムに対応させる必要があります。

下記のようなデータスキーマに書き直す必要があります.

{
    "Attributes": [
        {
            "AttributeName": "timestamp",
            "AttributeType": "timestamp"
        },
        {
            "AttributeName": "target_value",
            "AttributeType": "float"
        },
        {
            "AttributeName": "item_id",
            "AttributeType": "string"
        }
    ]
}

予測子をトレーニングする時間および予測を生成する時間

データを Amazon Forecast にインポート後に予測子をトレーニングします.

予測子 (トレーニング済みモデル) を作成するには、アルゴリズムと、行う予測の数 (長さ × 頻度) を選択します。

f:id:sadayoshi_tada:20190908223416p:plain

トレーニングの時間ですが30分以上はかかった印象なので,すぐにはトレーニング済みモデルが出力されないものと思っておくと良いです.また,予測の生成も時間を要します.下記のように数分以上とありますが,40分以上は待つ必要があります.

Amazon Forecast で、予測の作成が終了するまで待ちます。このプロセスには、数分以上かかることがあります。予測が作成されると、進行状況は [Active] に変わります。さらに、ダッシュボードの上部にあるバナーが変わり、次のメッセージが表示されます。

f:id:sadayoshi_tada:20190908225651p:plain

フルマネージドサービス型の時系列予測

フルマネージドサービス型の時系列予測を行う Amazon Forecast を使ってみて思ったのは,データが揃っていればフルマネージドのメリットは存分に享受できます.EC2 のプロビジョニングやトレーニング済みのデータモデルを作ったりをボタン数クリックで賄えて,予測モデルが生成されるのは時系列予測に詳しくなくても扱えます.

まとめ

Amazon Forecast のサービス概要や仕組み,サンプルデータを使った時系列予測を行った際の注意点や理解したことをまとめました.次は,以前ツイートしたデータを突っ込んでみようと思います！

同僚から体重と食事のデータを入れみたら？ってアドバイスもらったので突っ込んでみたい
「Amazon Forecast」が正式リリース。過去の時系列データを与えるだけで機械学習による予測をしてくれる、専門知識不要のサービス－ Publickey https://t.co/9GCsyA1run
— SADAYOSHI TADA🎉 (@tada_infra) September 5, 2019

2019-09-01

特定のリージョンのみのリソース制御するための IAM ポリシー設定

AWS IAM AWSCLI

タダです.

IAM 権限の制御としてリージョンレベルで制御したい要件が出てきたので調べてみたところ, aws:RequestedRegionで制限できるようなので検証した結果をブログにまとめます.なお,今回東京リージョンとソウルリージョンに EC2 を起動している状況で読み取り権限は全リージョン有効ではあるが, EC2 への変更権限や起動,停止といった権限は東京リージョンのみに限定する IAM ポリシーを設定して検証しました.

検証イメージ図 f:id:sadayoshi_tada:20190902160553p:plain

検証した IAM ポリシー

検証で使った IAM ポリシーは以下の通りです.このポリシーを IAM ユーザーに関連づけて東京とソウルの EC2 を起動,停止してみます.期待する結果は東京リージョンのサーバーは起動と停止はうまくいき,ソウルリージョンのサーバーは停止も起動もできない,です.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InstanceConsoleReadOnly",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "InstanceWriteRegionRestricted",
            "Effect": "Allow",
            "Action": [
                "ec2:ModifyInstancePlacement",
                "ec2:TerminateInstances",
                "ec2:ImportInstance",
                "ec2:StartInstances",
                "ec2:MonitorInstances",
                "ec2:RunScheduledInstances",
                "ec2:ResetInstanceAttribute",
                "ec2:RunInstances",
                "ec2:ModifyInstanceAttribute",
                "ec2:StopInstances",
                "ec2:AssociateIamInstanceProfile",
                "ec2:ModifyReservedInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": [
                        "ap-northeast-1" <= 東京リージョンのみ指定
                    ]
                }
            }
        }
    ]
}

AWS ドキュメント