AWS SAMでError: PythonPipBuilder:None - Binary validation failed!
小ネタです。 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を読んだ
面白かったでまとめてみたいと思います。
ネタバレありです。
簡単にさわりを知りたい方は下記を見ると良いと思います。
本書の最初の部分が、下記でプレゼンされています。
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フローログは既に作成済みの前提です。
では設定画面を見ていきます。
上記設定をし、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」（赤枠）ごとに分類がされています。
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で検出されるフィールドを表示します。
結果表示
上記のように設定し、ある程度時間が経過すると、
VPCフローログの結果が下記のように表示されていました。
（結構待たないと表示されませんでした。15分ぐらい）
トップN的に分析することが可能となります。
アプリログも分析できるようなので、例えば、エラーが出ている場合の
機能IDを早く知りたいとかのケースに役に立ちそうだと思いました。
他にも有益な用途で利用されている方が入れば教えて頂けますと幸いです。
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のページからエンドポイントを作成します。
2)EC2のIAM設定
EC2をIAM Roleを設定します。
ポリシー名「AmazonEC2RoleforSSM」が付与されたIAMロールをEC2へ適用します
ロールの作成
上記をEC2へ適用します
3)NW設定(EC2,VPCendpoint)
VPCエンドポイントのセキュリティグループのインバウンド設定に、
EC2に設定したセキュリティグループIDを設定します。
4)SSM Agentのアップデート
必要があれば、SSMのAgentをアップデートします
Run CommmandにAWS-UpdateSSMAgentがあるため、
こちらを対象のEC2に実行します。
もしランコマンドの画面で対象のEC2が画面に出てこなかったら
手動でEC2にログインし、Agentをアップデートします。
方法は下記を参照ください。
この場合は外部との通信が可能なようネットワーク設定を一時的に更新します。
5)セッションマネージャ実行
準備ができたら接続します。
セッションマネージャから対象のインスタンスを選択し、
セッションの開始を実行します。
おまけ
#ログイン後、ルート昇格もできるようです
sudo -s
[root@ip-172-30-1-65 ssm-user]#
#ルート昇格もできるようです
sudo -s
[root@ip-172-30-1-65 ssm-user]#
netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
#また、セッション履歴も残るため、ログイン履歴等もAWS側から管理できます
Linuxであれば踏み台いらずなのはかなり良いと思います。
ぜひ機会があればお試しください。
AWS Autoscaling設定時に気をつけたいこと・アンチパターン
AWSのAutoscalingという機能があります。
これは便利な機能なのですが、アプリケーションもそれに対応した作りになっていた方が相性が良いです。
逆を言えば、AWSのベストプラクティスに従わないと途端に運用が大変になってしまいます。
検討時に気づいて欲しい・・・そんな願いを元にAutoscalingを設定する際に気をつけたいことをまとめてみました。
アプリケーションの作り
ライセンス関連
オートスケーリングにて増えたEC2内のライセンスが有効かどうかです。
起動して、特別な作業をしないとライセンス関連でエラーが出るケースがあります。
エラーにならなくても大人なのでライセンスはちゃんとしましょう。
AMIの運用
AMIとかをプログラムで世代管理している場合、設定したAMIが無くなることがあるため注意です。
AMIが削除されている場合はスケールアウトしてくれません。
Autoscalingの動きを認識しているか
稀に勘違いしている人がいるのですが、
Autoscalingは決められたAMIを元にEC2をスケールアウトします。
起動中のEC2をコピーして増えてくれると勘違いしている人がいるので
そのほか、AMIの更新運用をどうするか等の問題もありますが、
とりあえず上記は障害に繋がるので、まずは上記観点を気をつけると良いと思います。
誰かの参考になれば幸いです
GCP Professional Cloud Network Engineer に合格しました。
先日会社から要請があり、GCPの資格試験を受けました。
Professional Cloud Network Engineer になんとか合格できましたのでブログ書こうと思います。
勉強したこと
試験範囲は下記です。
基本的には、ここに出てくる用語を潰すようにドキュメントを読み理解しました。
あと、模試も受けておいた方が良いです。
解説にリンクが貼ってくれてあるので、それを見て勉強しました。
cloud.google.com
参考にした合格体験記
この辺が参考になりました。
github.com
medium.com
yomon.hatenablog.com
具体的にどこが出たかは規約により言えませんが、
今の所英語でしか受けれないようで、
もし受けられる方は知ってる用語の英語版を眺めておくと良いと思いました。
AWS Transcribe（Speech to text）が日本語対応したので試してみた！あとGoogleとも比べてみた！
AWSのTranscribeが待望の日本語対応をしてくれました！
早速どんなものか試してみたいと思います。
また同じSpeech To Textのサービスを持っているGCPでの動作比較もしてみました。
今回は電話の会話記録の音声データでスピーカが2人存在するデータを利用しました
AWS Transcribe
Transcribeのstart_transcription_jobを実行します。
スピーカは2人のため下記のパラメータを利用しました。
'ShowSpeakerLabels': True, 'MaxSpeakerLabels': 2,
AWSの方は勝手に形態素解析まで実施してくれているのか、
文章がかなり途切れ途切れになりました。
{ "jobName": "samplejob2", "accountId": "xxxxxxxxxxxxx", "results": { "transcripts": [ { "transcript": "もしもし はい あ お 願い し ます お 電話 ありがとう ござい ます か 解析 会社 さん xxxxxxxxxxx モバイル です ホーム ページ を 見 た 言わ せ て いただき まし た ありがとう ござい ます エネルギー 使い 放題 プラン に つい て 聞き たい わ こちら の 契約 期間 の 縛り は あり ます か? こちら は 最低 六 カ月 三 六 カ月 契約 いただく 必要 が ござい ます もちろん か月 より も 短い 期間 工 解約 さ れ た 場合 違約 金 が 発生 し ます 現金 は いくら です か 一 万 円 です 分かり まし た あと パケット 使い 放題 だ と 思い ます が 速度 制限 は あり まし た 正確 な 数字 を 公開 でき ない の です が が ある 一定 の 利用 料 を 超え ます と 翌日 に 速度 制限 が かかる こと が 報告 さ れ て い ます あ 分かり まし た ありがとう ござい ます その 他 ご 不明 な 点 は ござい ます か 大丈夫 です ありがとう ござい ます で は ありがとう ござい まし た 担当 鈴木 が 対応 さ せ て 頂き まし た お 電話 ありがとう ござい まし た ありがとう ござい まし た うん はい" } ], "speaker_labels": { "speakers": 2, "segments": [ ・・・・・・・・・・・・・・・・・・・・・・・・ 長いので省略します。 下記のようにスピーカ毎・単語毎のItemも出力されていました。 ・・・・・・・・・・・・・・・・・・・・・・・・ "items": [ { "start_time": "4.94", "end_time": "5.55", "alternatives": [ { "confidence": "1.0", "content": "もしもし" } ], "type": "pronunciation" }, { "start_time": "6.34", "end_time": "6.65", "alternatives": [ { "confidence": "0.99", "content": "はい" } ], "type": "pronunciation" }, { "start_time": "6.66", "end_time": "7.58", "alternatives": [ { "confidence": "0.974", "content": "あ" } ], "type": "pronunciation" }, { "start_time": "7.59", "end_time": "7.65", "alternatives": [ { "confidence": "0.906", "content": "お" } ], "type": "pronunciation" }, { "start_time": "7.66", "end_time": "8.09", "alternatives": [ { "confidence": "1.0", "content": "願い" } ], "type": "pronunciation" }, { "start_time": "8.1", "end_time": "8.24", "alternatives": [ { "confidence": "1.0", "content": "し" } ], "type": "pronunciation" }, { "start_time": "8.25", "end_time": "8.55", "alternatives": [ { "confidence": "1.0", "content": "ます" } ], "type": "pronunciation" }, { "start_time": "10.44", "end_time": "10.51", "alternatives": [ { "confidence": "0.972", "content": "お" } ], "type": "pronunciation" },
GCP
続いてGCPです。
AWSの方で利用したのと同じ音声ファイルを利用し
Cloud Speech-to-Textを実行してみます。
{ "conversation": [ { "transcript": "はい", "confidence": 0.9321745038032532 }, { "transcript": "お電話ありがとうございます株式会社xxxxxxxxxxxxxモバイルです", "confidence": 0.9289773106575012 }, { "transcript": "ありがとうございます", "confidence": 0.9539141654968262 }, { "transcript": "ホームページを見ると言わせていただきました良い使い放題プランについてお聞きしたいですかこちらは契約期間の縛りはありますか", "confidence": 0.891223669052124 }, { "transcript": "こちらは最低6ヶ月間6ヶ月契約いただく必要がございます", "confidence": 0.9191603064537048 }, { "transcript": "もし6ヶ月よりも短い期間でご解約された場合違約金が発生してます", "confidence": 0.9336251616477966 }, { "transcript": "違約金はいくらですか", "confidence": 0.9120486974716187 }, { "transcript": "1万円です", "confidence": 0.9227500557899475 }, { "transcript": "わかりました本当ポケット着たい放題だと思いますが速度制限はありますか", "confidence": 0.9032462239265442 }, { "transcript": "正確な数値は公開できないのですが", "confidence": 0.9470984935760498 }, { "transcript": "日課である一定の量を超えますと翌日に速度制限がかかることが報告されています", "confidence": 0.9332273602485657 }, { "transcript": "分かりましたありがとうございます", "confidence": 0.9206825494766235 }, { "transcript": "その他ご不明な点はございますか", "confidence": 0.952523410320282 }, { "transcript": "大丈夫ですありがとうございます", "confidence": 0.932539701461792 }, { "transcript": "ではありがとうございました担当鈴木が対応させていただきましたお電話ありがとうございました", "confidence": 0.9320775866508484 }, { "transcript": "ペロ寝ました", "confidence": 0.7940347790718079 } ] }
ペロ寝ましたって何だって思うかもしれませんが、「ありがとうございました」を言っています。
それはさておきGCPの方の方が制度が高そうです。
その他2,3個の音声ファイルで試してみたのですが
私の印象ではまだGCPの方が精度が高いように感じます。
精度に関してはAWSもこれから上がっていくのかと期待しています。
APIの使い方自体はAWSの方がシンプルで使いやすい印象を受けました。
またアウトプットファイルがS3に格納されるのですが、
S3のファイルputイベントと、他のサービスを組合せるなど
面白そうな使い方ができそうです。
（GCPの場合は音声ファイルのサイズによりオプションを変える等の面倒な点があります）
