私の戦闘力は53万です

awsとgcpについて書きます

AWS Certified Machine Learning – Specialtyに合格できました

先日、AWS Certified Machine Learning – Specialtyに合格できました。

勉強方法

まずは模試試験を受け、自分のレベルと、何を学ばないと行けないかを把握しました。
aws.amazon.com

その後、勉強方法について調べました。
こちらがよくまとまっていました。
qiita.com

ただこちら情報量が多く、結局何を勉強するか悩んだのですが、
私の場合、基礎をしっかり学びたい想いがあったので、
模試の結果から併せて考え、下記を中心に勉強しました。

こちらを1冊読みきりました。
www.amazon.co.jp

こちらは前半の半分程度を読みました。
www.amazon.co.jp

こちらは前半の2割程度を読みました。
www.amazon.co.jp

ある程度バランス取りながら上記のオライリーの本を読んでいたところ
試験日も近くなったので、仕上げでSagemakerのドキュメントを読み
本試験を受けてみたら合格できました。

結果は750点が合格ラインで、800点程度でした。

あと私は試験終わってから知ったのですが、
各アルゴリズムの概要を知るのに、下記のyoutubeチャンネルが結構分かりやすかったです。
本を読んでみても分からんという場合、見てみると良いと思います。
www.youtube.com

【EFS Single File Restore】AWS backupとEFSの連携でファイル単位のリストアを試してみる

aws EFS

AWS BackupでEFSとの連携が便利になり、
EFSでのファイル単位のリストアができるようになりました。
機能を使ってみる機会がありましたのでメモ的に書いてみます。
aws.amazon.com

ユースケースとしては、ユーザやシステムが誤ってファイルを消してしまった場合のリカバリが考えられます。
ドキュメントの細かい箇所を読み込んで行くと、
おおよそ下記のメリット/デメリットがあることが分かりました。

メリット

  • AWS Backupは増分バックアップなので容量を無駄に取りすぎない
  • EFSの安価ストレージクラス（IAとか）関係なく利用可能

デメリット

  • 復元に時間（数分程度）がかかる
  • 復元の容量に応じて料金が発生する

検証準備

まずは検証の準備です。
EC2にEFSをマウントし、EFS内に適当なファイルを2つ作成します。

ls -lh /mnt/efs/test/bkup/
合計 8.0K
-rw-rw-r-- 1 ec2-user ec2-user 2  1月 28 03:10 1.txt
-rw-rw-r-- 1 ec2-user ec2-user 2  1月 28 03:10 2.txt

AWS Backupで、オンデマンドバックアップ(EFS)を取得します

f:id:remmemento:20200204000308p:plain
AWS Backup

その後、EFS内のファイルを一つ消してみます

rm /mnt/efs/test/bkup/1.txt 
ls -lh /mnt/efs/test/bkup/
合計 4.0K
-rw-rw-r-- 1 ec2-user ec2-user 2  1月 28 03:10 2.txt

リストア実施

上記で消してしまったファイルをリストアします。
AWS Backupの画面から、ファイルリストアを実行します。

f:id:remmemento:20200204000923p:plain
パス指定
ここで注意なのが、パスの指定方法です。
パスはマウントポイントからのパスを記入します。
上記の例は、下記の場合の例です。
マウントポイント「/mnt/efs」
ファイルフルパス「/mnt/efs/test/bkup/1.txt」
指定するパス「/test/bkup/1.txt」
f:id:remmemento:20200203235413p:plain
リストアが実行されると復元がジョブとなり、コンソールで確認できます。
ジョブが完了すると、マウントポイント直下に
「マウントポイント/aws-backup-restore_*」の形式で
ファイルがリストアされています。

ls -ld /mnt/efs/aws-backup-restore_*
drwxr-xr-x 3 ec2-user ec2-user 6144  1月 28 03:09 /mnt/efs/aws-backup-restore_2020-01-29T09-05-15-134Z
drwxr-xr-x 4 ec2-user ec2-user 6144  1月 28 03:09 /mnt/efs/aws-backup-restore_2020-01-29T09-20-26-282Z


ちなみに、バックアップ中に指定したファイルが存在しない場合は、
空のフォルダが作成されていました（ただし復元ジョブは成功の扱い）

ls -lh /mnt/efs/aws-backup-restore_2020-01-29T09-05-15-134Z/
合計 36K
drw--w---- 2 root root 38K  1月 29 09:05 aws-backup-lost+found_2020-01-29T09-05-15-135Z


上記はファイル単位でのリストアでしたが、
フォルダ単位のリストアも可能なため、
誤操作によるファイル削除等のリカバリには有効な機能です。
AWS EFSを利用する際には利用を検討してみる価値ありです。

AWS SAMでError: PythonPipBuilder:None - Binary validation failed!

aws SAM

小ネタです。 SAMで「sam build」したところ下記のエラーが出てしまいました。

Build Failed
Error: PythonPipBuilder:None - Binary validation failed!

sam build --debugで詳細見ると、
ローカルのpython versionがpython3.7だけど
runtimeを3.8に指定していたことが原因のようでした。
runtimeを3.7にして実行すると正常に動作しました。

ダニエルピンク モチベーション3.0を読んだ

break

面白かったでまとめてみたいと思います。
ネタバレありです。

モチベーション３．０　持続する「やる気！」をいかに引き出すか (講談社＋α文庫)

モチベーション３．０　持続する「やる気！」をいかに引き出すか (講談社＋α文庫)

簡単にさわりを知りたい方は下記を見ると良いと思います。
本書の最初の部分が、下記でプレゼンされています。
www.ted.com

短めにまとめ

既存のモチベーション維持方法は古く、
科学的に正しいと立証されている方法と、
（本書ではモチベーショ3.0と呼ぶ。自律性、熟達、目的にフォーカスした方法）
現在の企業や学校で行われている方法
（本書ではモチベーション2.0と呼ぶ。いわゆるアメとムチ。）
には乖離がある。
本書ではモチベーショ3.0の解説と、
実際の適用例、実験結果、2.0から3.0へ移す方法例をあげています。
あと、レアケースでアメとムチがうまくいくケースについても触れています。

モチベーション3.0とは

下記を中心に人間のモチベーションが下がる/上がるをコントロールすること。

(1)自律性
自己決定できること。課題、時間、手法について自分たちで考え行動できること。
上司から非効率なやり方を強制されるとモチベーションが下がり、
好きにやって良いよと言われると楽しんでやれるといった具合のことです。

(2)熟達
より上を求めて向上すること。
難しすぎず、易しすぎない業務に取り組み
自分のレベルをアップさせていくことを表します。

(3)目的
なぜやるのかを明示すること。利益以外の社会的な目標。

人間のモチベーションがアメとムチ（報酬と罰）だけとすると、
世の中には説明できないことがあります。
例えばボランティア、wikipediaの発達、オープンソースの発達・・・。
人には本来、自分で考えて行動したい、
より向上したい、人の役に立ちたい、、といった願望があり、
それらに任せて仕事ができる環境を作ると
よりモチベーションが高い状態で仕事ができるといった考え方です。

誰しもが上記に当てはまる訳ではないと思いますが、
確かに、良いエンジニアと話すときは、こういった姿勢が感じられます。
また、良いエンジニアが集まる会社は上記の雰囲気が感じられます。
今の世の中、上司に素直に言われたことだけをやる人は価値が低くて、
自律的に学習して向上する筋力が必要とされることを改めて感じました。
また、マネジメントでは、単に指示を出すことでなく、
こういった雰囲気やルールを作る能力が求められていきそうと感じました。
そう考えるとサーバントリーダシップと繋がってまた面白いです。

CloudWatch Contributor Insightsを触ってみる

CloudWatch Contributor Insightsを触ってみる機会がありましたので、 備忘がてらブログに書きます。

機能概要

ドキュメントにも記載はありますが、もう少し噛み砕くと、
cloudwatch logsの特定箇所を抽出し、
トップN分析的に可視化することができます。
例えば下記をトップN分析的にランキング表示することが可能です。

  • VPCフローログで、送信元 IP アドレスおよび送信先 IP アドレスごとのバイト転送量を出力する
  • アプリログで、特定のエラーコードごとの機能IDを出力する
  • ECSのコンテナログで、アウトバウンド通信している先のIPをランキング的に出力する

下記で具体的に設定してみました。

表示項目の選定

CloudWatch Contributor Insightsでは、
logsからどの項目を抽出し表示するかを設定します。
（結果的には裏でJSONが作成されます）
そのJSONを作成することをルール作成と呼んでいます。

今回は下記を作成するとします。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/ContributorInsights-Rule-Examples.html
例：VPC フローログを元に、送信元 IP アドレスおよび送信先 IP アドレスごとのバイト転送 を出力する
※VPCフローログは既に作成済みの前提です。

では設定画面を見ていきます。

f:id:remmemento:20200119225222p:plain
設定1

f:id:remmemento:20200119225242p:plain
設定2

上記設定をし、JSONをみると下記のようになっています。
※分かりやすくするためにコメント入れていますので、
設定原本は上記のドキュメントを参照ください。

{
    "Schema": {
        "Name": "CloudWatchLogRule",
        "Version": 1
    },
    "LogGroupNames": [
        "/aws/containerinsights/sample-cluster-name/flowlogs"
    ],
    "LogFormat": "CLF",
    "Fields": {
        "4": "srcaddr",#フィールドとしてTSV的に4番目の項目をsrcaddrとして扱う
        "5": "dstaddr",#フィールドとしてTSV的に5番目の項目をdstaddrとして扱う
        "10": "bytes"#フィールドとしてTSV的に10番目の項目をbytesとして扱う
    },
    "Contribution": {
        "Keys": [
            "srcaddr",#軸として利用する
            "dstaddr"#軸として利用する
        ],
        "ValueOf": "bytes",#AggregateOnがSumの場合に利用可。計算対象のフィールドがあれば指定する
        "Filters": []
    },
    "AggregateOn": "Sum"
}

設定値の意味

上記の設定ファイルの意味を書いていきます。

Contribution

Contributionではログから抽出したい項目を指定します。
今回は「送信元 IP アドレスおよび送信先 IP アドレスごとのバイト転送 」を
出力したいため、 関連要素となる下記を指定します。
送信元 IP アドレス：srcaddr
送信先 IP アドレス：dstaddr
バイト転送：bytes

上記の項目をどのように表示するかにより、
さらに下記に分けて記載します。

Contribution.Keys

分類するディメンションを指定します。
具体的には、最終アウトプットの下記を見ると分かりやすいと思います。
Contribution.Keysで指定された、項目ごとに分類がされています。
今回の例では、「送信元IP」、「送信先IP」（赤枠）ごとに分類がされています。

f:id:remmemento:20200119231223p:plain
output

Contribution.ValueOf

数値合計を算出する際、単に回数の合計でなく、
計算結果を表示させたい場合等に利用します。
今回の例では「bytes」を指定しており、
フロー中に転送されたバイト数の合計を算出しています。

Fields

Fieldsは、各項目のエイリアスを定義します。
今回の例ではVPCフローログの位置情報は
下記のVPCフローログのフォーマットを参照することで把握できます。
「srcaddr」が4つ目の位置に存在することが分かります。
そのため「srcaddr」を設定画面で「4」と指定しています。
ここでエイリアスを指定することで
srcaddrをContribution中でも記載可能になります。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide//flow-logs.html

またその他の項目についてもcloudwatch insightで
検出されるフィールドが選択可能です。
参考でcloudwatch insightで検出されるフィールドを表示します。

f:id:remmemento:20200119225828p:plain
insight1
f:id:remmemento:20200119225850p:plain
insight2
例えば上記から「dstPort」等を利用することも可能です。

結果表示

上記のように設定し、ある程度時間が経過すると、
VPCフローログの結果が下記のように表示されていました。
（結構待たないと表示されませんでした。15分ぐらい）

f:id:remmemento:20200119232154p:plain
result
上記のようにログ中の特定項目を抜き出し、
トップN的に分析することが可能となります。
アプリログも分析できるようなので、例えば、エラーが出ている場合の
機能IDを早く知りたいとかのケースに役に立ちそうだと思いました。

他にも有益な用途で利用されている方が入れば教えて頂けますと幸いです。

AWS 踏み台なしで接続 SSMセッションマネージャ

aws SSM
AWSではSSMセッションマネージャーを使うことで
踏み台サーバなしでPrivateのEC2へ接続できます。
 
ザックリとしたサンプル手順は下記のようになります。
 
1)VPCエンドポイントを作成
2)EC2のIAM設定
3)NW設定(EC2,VPCendpointのセキュリティグループ設定)
4)SSM Agentのアップデート
5)セッションマネージャ実行
 
下記詳細を紹介します。 

1)VPCエンドポイントを作成 

もしNATゲートウェイを利用している場合はここはスキップで問題ありません。
 
完全プライベートなsubnetの場合、VPCエンドポイントを作成します
(1) com.amazonaws.region.ssmmessages: 
(2) com.amazonaws.region.ec2messages:
　 このエンドポイントを通じて、
　 Systems Manager は SSM エージェントから 
　 Systems Manager サービスへの呼び出しを行います。
 
VPCのページからエンドポイントを作成します。

f:id:remmemento:20191210064643p:plain

 
 
2)EC2のIAM設定
EC2をIAM Roleを設定します。
ポリシー名「AmazonEC2RoleforSSM」が付与されたIAMロールをEC2へ適用します
 
ロールの作成

f:id:remmemento:20191210064706p:plain

f:id:remmemento:20191210064726p:plain

f:id:remmemento:20191210064850p:plain

 
 
上記をEC2へ適用します

f:id:remmemento:20191210064809p:plain

 
 
 
3)NW設定(EC2,VPCendpoint)
VPCエンドポイントのセキュリティグループのインバウンド設定に、
EC2に設定したセキュリティグループIDを設定します。

f:id:remmemento:20191210064918p:plain

 
 
4)SSM Agentのアップデート
必要があれば、SSMのAgentをアップデートします
Run CommmandにAWS-UpdateSSMAgentがあるため、
こちらを対象のEC2に実行します。
もしランコマンドの画面で対象のEC2が画面に出てこなかったら
手動でEC2にログインし、Agentをアップデートします。
方法は下記を参照ください。
この場合は外部との通信が可能なようネットワーク設定を一時的に更新します。
 

f:id:remmemento:20191210064936p:plain

 
 
 
5)セッションマネージャ実行
準備ができたら接続します。
セッションマネージャから対象のインスタンスを選択し、
セッションの開始を実行します。

f:id:remmemento:20191210064958p:plain

おまけ
#ログイン後、ルート昇格もできるようです
sudo -s
[root@ip-172-30-1-65 ssm-user]#
 
#ルート昇格もできるようです
sudo -s
[root@ip-172-30-1-65 ssm-user]#
 
#https overでsshを実現しているようですね
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 ip-172-30-1-65.ap:35812 ip-172-30-0-5.ap-:https ESTABLISHED
tcp        0    929 ip-172-30-1-65.ap:35790 ip-172-30-0-5.ap-:https ESTABLISHED
tcp        0      1 ip-172-30-1-65.ap:60166 54.240.225.173:https    SYN_SENT
tcp        0      0 ip-172-30-1-65.ap:42598 ip-172-30-1-38.ap:https ESTABLISHED
 
#また、セッション履歴も残るため、ログイン履歴等もAWS側から管理できます
 

f:id:remmemento:20191210065021p:plain

Windowsの場合はPowershellになるため、GUIでの操作はできませんが、
Linuxであれば踏み台いらずなのはかなり良いと思います。
ぜひ機会があればお試しください。
 
 

AWS Autoscaling設定時に気をつけたいこと・アンチパターン

aws Autoscaling

AWSのAutoscalingという機能があります。
これは便利な機能なのですが、アプリケーションもそれに対応した作りになっていた方が相性が良いです。
逆を言えば、AWSのベストプラクティスに従わないと途端に運用が大変になってしまいます。
検討時に気づいて欲しい・・・そんな願いを元にAutoscalingを設定する際に気をつけたいことをまとめてみました。

アプリケーションの作り

EC2内部のアプリケーションがAutoscalingに適した作り（ステートレス）になっているか

これがもっとも重要です。
Autoscalingは、特的の閾値（CPU利用率とか）でインスタンスを増減させます。
つまり、EC2がいつ増えても減っても良いように作っていなくてはいけません。
下記はよくある例です。

スケールインでEC2が削除された場合、
インスタンス内部のログやセッションが削除されます。
そのため、ログファイルを失ったり、
ログインユーザがいきなりログアウトするような事象が発生します。

そのため、上記のよくあるケースに対してはアプリを改良します。下記が対応例です。

  • インスタンス内にファイルを配置しない（EFSやS3を利用する）
  • インスタンス終了時等にログ等の消えて困るファイルをS3等に退避する
  • セッションをインスタンス内に保持しないようにする（elasticache等を利用）
  • LBのスティッキーセッションを利用する（AWS非推奨）

ライセンス関連

オートスケーリングにて増えたEC2内のライセンスが有効かどうかです。
起動して、特別な作業をしないとライセンス関連でエラーが出るケースがあります。
エラーにならなくても大人なのでライセンスはちゃんとしましょう。

AMIの運用

AMIとかをプログラムで世代管理している場合、設定したAMIが無くなることがあるため注意です。
AMIが削除されている場合はスケールアウトしてくれません。

Autoscalingの動きを認識しているか

稀に勘違いしている人がいるのですが、
Autoscalingは決められたAMIを元にEC2をスケールアウトします。
起動中のEC2をコピーして増えてくれると勘違いしている人がいるので


そのほか、AMIの更新運用をどうするか等の問題もありますが、
とりあえず上記は障害に繋がるので、まずは上記観点を気をつけると良いと思います。
誰かの参考になれば幸いです