下記を参考にさせていただきました。 環境 $ cat /etc/system-release Amazon Linux release 2 (Karoo) Node.jsのインストール $ curl -sL https://rpm.nodesource.com/setup_12.x | sudo bash - $ sudo yum install -y nodejs Yarnのインストール $ curl -sL https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo $ sudo yum install -y yarn 以上で完了です

VPC Peering接続は、２つのVPC間でトラフィックをルーティングすることができるネットワーク接続。 各VPCのインスタンスも同じネットワーク内に存在するかのように、相互に通信することができる。 詳しくはこちら。 そこで、下記構成図を用意し、インスタンス2に対して名前解決を行う。 VPC Peeringの設定 VPC -> ピアリング接続 -> ピアリング接続の作成 接続するVPCを選択する。 VPCを選択したら、”ピアリング接続の作成”をクリック。 VPC Peeringを作成後、ステータスが”承認の保留中”となっているので、 アクション -> リクエストの承諾　をクリックする。 接続が確立されると、ステータスが”アクティブ”に変わる。 ルートテーブルの設定 Peeringの設定が完了すれば、続いてルートテーブルの設定に移る。 VPC -> ルートテーブル -> ルートテーブルを選択 -> ルートタブ -> ルートの編集 ルートの編集では、送信先に相手VPCのネットワークを選択、ターゲットには先程作成したVPC Peeringを選択する。 各VPCのルートテーブルで設定する。 EC2インスタンスを払い出してdigコマンドで名前解決 各VPCにEC2インスタンスを払い出す。 インスタンス１で、dig (プライベート IPv4 DNS) を打ち込むと、インスタンス２のプライベートIPが帰ってきた。 VPCが繋がっていることを確認できた。

背景 重要なデータのバックアップのためにクロスリージョンレプリケーションを使用していても、その転送プロトコルに欠陥があれば問題である。こういった背景からレプリケートする際のデータ転送に使用されるSSL/TLSバージョンを知りたかった。以下の書き方ではSSLなのかTLSなのか、また、詳しいバージョンについてもわからない。 Q: レプリケーションプロセス全体で、オブジェクトは安全に転送され、暗号化されますか? はい。オブジェクトはレプリケーションプロセスの間ずっと暗号化されたままとなります。暗号化されたオブジェクトは、SSL 経由で送信元リージョンから送信先リージョンまで (CRR) または同じリージョン内で (SRR) 安全に転送されます。 以下はIPAの資料だが、バージョンによって推奨・非推奨が分かれている。 SSL/TLS 暗号設定ガイドライン改定及び鍵管理ガイドライン作成のための調査・検討 -調査報告書- AWSもドキュメントに記載している通り、TLS1.2 以降を推奨している。単にHTTPSだからといって安心できない。 検証方法 クロスアカウントによるレプリケーションの際、バケットポリシーでs3:ReplicateObjectの条件キーとして、s3:TlsVersionを指定する。これを0.1ずつ増減させる。 "Action": [ "s3:ReplicateObject", "s3:ReplicateDelete" ], "Resource": "arn:aws:s3:::cross-account-bucket/*", "Condition": { "NumericGreaterThan": { "s3:TlsVersion": 1.1 } } クロスアカウントなので明示的にActionを許可する必要がある。つまり、上記ポリシーでレプリケートできるならば、TLSのバージョンは少なくとも1.2であることがいえる。 検証の結果、東京-東京、東京-バージニアはいずれもTLS1.2であることがわかった。 参考記事

プログラミング勉強日記 2021年4月27日 CIDRとは 　Classless Inter-Domain Routingの略で、「サイダー」と読む。サブネットマスクの値を設定して同じネットワークとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法。(サブネットマスクについては昨日の記事で触れてる。) 　2進数表記にしたときにサブネットが指定する数が利用できないようにロックされて変更できないようになり、ロックされていない桁分のビット間が有効なIPアドレスとして活用できる。 　サブネットマスクによって固定される範囲をネットワーク部、利用可能な範囲をホスト部という。10.0.0.0/16の場合、10.0がネットワーク部で0.0 ~ 255.255の部分がホスト部になる。 　IPアドレスの範囲は今後の拡張も踏まえて、十分な余裕を持ちつつ多すぎないレンジを指定する。単なるネットワークそのものを使うときは/16を、そのさらに細かくサブネットで分けるときは/24を使われることが多い。 サブネットマスク サブネット当たりのIPアドレス数 /16 65,534 /18 16,384 /20 4,096 /22 1,025 /24 256 /26 64 /28 16

前回、LaravelだけGit管理するようにした。 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その参 ただ、プッシュする度にユーザー名とパスワードを入力するのが面倒くさいので、SSH接続にする。 マシンスペック Mac mini 2018 macOS Catalina（10.15.x） Intel Core-i7 3.2GHz 6コア メモリ 32GB SSD 512GB Docker環境 Nginx 最新版 PHP（PHP-FPM）7.2.x MySQL 5.7.x Composer 1.x Laravel 5.6.x やること リポジトリにSSH接続する 前提 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その参で環境構築済み GitリポジトリにSSH接続する SSHキーペア作成 $ cd ~/.ssh $ ssh-keygen -t rsa -b 4096 -C "GitHubメールアドレス" Generating public/private rsa key pair. Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): <ENTERキー押す> Enter passphrase (empty for no passphrase): <好きなパスワードを入力> Enter same passphrase again: <パスワード再入力> ・・・ +----[SHA256]-----+ $ ls authorized_keys id_rsa id_rsa.pub $ cat id_rsa.pub ssh-rsa ・・・ 上記の ssh-rsa ・・・ をコピーしておく。 GitHubにSSH公開キー登録 上記でコピーした ssh-rsa 〜 を Key にペーストする。 GitHubとの接続を確認する。 $ ssh git@github.com ・・・ Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,52.69.186.44' (RSA) to the list of known hosts. Enter passphrase for key '/home/ec2-user/.ssh/id_rsa': <SSHキーペア作成で設定したパスワード> PTY allocation request failed on channel 0 Hi bobtabo! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed. SSHエージェントに鍵を登録する。 $ ssh-agent bash $ ssh-add ~/.ssh/id_rsa Enter passphrase for /home/ec2-user/.ssh/id_rsa: <SSHキーペア作成で設定したパスワード> Identity added: /home/ec2-user/.ssh/id_rsa (/home/ec2-user/.ssh/id_rsa) HTTPSでクローンしたLaravelを削除 $ cd ~/environment/docker/src $ rm -fdR laravel SSHでクローンし直す $ git clone <上記でコピーしたリポジトリURL> laravel 例）git clone git@github.com:bobtabo/cloud9-laravel.git laravel クローンし直したので、下記を参考にLaravel環境を準備し直す。 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その壱#Laravel環境の準備 プッシュする 適当にファイルを作成する。 ステージに追加。 ローカルリポジトリにコミット。 リモートリポジトリへプッシュ。 何故かエラーになる。（ちなみに、プルもエラー） Log > git push origin master:master Warning: Permanently added the RSA host key for IP address 'xx.xx.xx.xx' to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. でも、コマンドでプッシュ出来た。 $ pwd /home/ec2-user/environment/docker/src $ cd laravel $ git push origin master Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Compressing objects: 100% (1/1), done. Writing objects: 100% (2/2), 301 bytes | 301.00 KiB/s, done. Total 2 (delta 1), reused 1 (delta 1) remote: Resolving deltas: 100% (1/1), completed with 1 local object. To github.com:bobtabo/cloud9-laravel.git c6255c3..c188ca5 master -> master Cloud9でSSH接続した際は、プル／プッシュはコマンド操作しよう！

はじめに 本日(2021/4/27)、AWS認定デベロッパーアソシエイト試験を自宅でオンライン受験しまして、 無事に合格することができました〜✨ 先週にはAWS認定ソリューションアーキテクトアソシエイト(SAA-C02)の試験にも合格していたので、 このイイ流れを活かして、ノリで取っちゃおうという作戦でした。 SAA-C02を取得していたので、勉強時間は１週間で済みました?‍♂️ 2021年4月中に3つの資格取得(1週間に1つペース)は、なかなかハードで心折れそうでしたが、なんとか気合いで乗り越えられ、自信にもつながりました！??✨ 受けるまでの準備、当日の出来事、心境等をもろもろ綴りたいと思います〜 TL;DR 試験の予約方法 勉強方法 当日の流れ 受けてみた感想とハプニング AWS認定試験 - 予約方法 予約方法は、AWS認定クラウドプラクティショナー試験を受験した時の記事にまとめましたので、 こちらご参照ください〜 AWS認定試験 - 勉強方法 今回の勉強方法は、ソリューションアーキテクトアソシエイトでもハンズオンを一部実施しましたが、出題されるAWSの各サービスにおけるハンズオンも一つ一つ交えてみました。 whizlabでPractice Testsを購入し(1000円くらい)、新しい方のPractice Test I~Vと+セクションテストを2周しました。 Practice Test - Oldは、旧型仕様のテスト問題なので、やらなくて大丈夫です。 本番のテストとシンクロ率がかなり高いので、Practice Test達を完璧にしたらいけると思います。 各模擬テストで時間を測りながら65問一気に解いて、解き終わったら、間違った問題の解説を読むって感じです。 最終的には、94%の正答率をFinal模擬テストで出せるくらいまで理解を深めました。（※Final Testは前日に受けた方がいいシミュレーション用のやつ） ハンズオンに取り組む AWSの公式Youtubeがあるので、操作の仕方や画面の仕様感を把握する。自分は以下のサービスを眺めました。 Code Deploy, Code Build, Code Pipeline Elastic Beanstalk API Gateway Lambda SNS, SQS Xray ECS Cognito AWS Training & Certificationで、動画を見ながら仮想ハンズオンをする。 この辺を見てみました。 SNS, SQS Elastic Beanstalk 「百聞は一見にしかず」 具体的なイメージに勝るものはありません。 やっぱり問題しか解かないと空想で終わってしまって、想像の世界で問題を解くことになるので、しっかりとハンズオンを交えると、具体的な操作や実装のイメージがより深まり、堅くなります！ AWS認定試験 - 当日の流れ Pearson VUEで自宅受験する場合、 チェックインが試験開始の30分前にあります。 自分は午前10時45分に予約しました。試験時間は通常130分です。 (※自分は、ESL +30申請したので、160分間で実施。) 時刻 アクション 7:10 起床 7:20 朝食(コーンフレーク)＋コーヒー+バナナ 7:30 ~ 8:45 ボッとする、嫁と雑談、決意を込めて祈る(厨二) 8:45 ~ 9:00 部屋と環境の最終セットアップ 9:00 ~ 9:10 あずきのチカラ アイマスクで目を温めて回復させる 9:10 ~ 10:10 参考書の問題を解く+Qiitaで見つけた問題解く 10:15 チェックイン 10:30 試験開始 12:30 試験終了 13:30 （本来の試験終了時間） ※早く試験を配布されたので、10:45の開始時刻よりも15分巻いて、10:30スタートした ※前回の10:30チェックインだと間延びして疲れてしまったので、15分早めた。 受験の注意点と事前準備のススメ OnVUE 試験を受ける際のヒント に記載されてますが、 とにかく自宅受験の条件がめちゃめちゃ細かい、かつ厳しく、 試験中ずっと試験官監視されながらレコーディングされるなど、 束縛がめちゃくちゃ激しいので、覚悟して望むこと。 メンヘラかよwww 「備えあれば憂いなし」です。 びっくりした条件 一部始終レコーディングされる、そのウェブカメラ内に常に自分の顔が映ってないとダメ 外れたら試験強制終了 第三者が試験スペースに侵入したり映り込んだらダメ 映り込んだりしたら即試験強制終了 プライベート空間にも関わらず、試験中は問題文を声に出して読んではダメ 試験官にとって耳障りだから 自宅のプライベートな受験スペースを試験官にウェブカメラ通じて全部晒します360° 部屋のポスターとかダメ 上着系も手に触れるエリアにあるとダメ 腕時計、財布とかも持ち込み禁止 デュアルモニターは禁止 前夜にできる限りセットアップしておく 部屋をキレイに整理整頓して、何も試験に影響を及ぼすようなものは置かないことが大事 システムテストは絶対にやっておくべき。 onVUEアプリをダウンロードして、マイクと通信環境、カメラの調子を確認します。 チェックイン時にダウンロードするのは時間がかかるから絶対にオススメしません。 実際に、今回アプリのアップデートがあって、再ダウンロードを促されました。 会社のパートナーアカウントに自分の認定を紐づける 会社がパートナーアカウントを持っていた場合、 自分の認定証を会社のパートナーアカウントに紐付けられるので、 こちらの記事を参考にして、どんどんアピールするといいと思います。 母国語が英語以外の人が英語で試験を受けると+30分申請ができる 実際にスケジュールを予約する前に、「試験での配慮希望の申請」ボタンをクリックしてESL +30 MINUTESの申請をしたら、本番のテストで見事30分延長されてました！ 30分のゆとりがある分、心の余裕につながり、見直しの時間も確保できた。 なんという高待遇✨ Q.オンライン監督試験では特別な配慮を受けることができますか。 A.英語を母国語としない受験者が英語のオンライン監督試験を受験する場合は、「ESL +30」により試験時間を 30 分延長できます。試験を予約する前に、AWS 認定アカウントを使用して、この延長をリクエストする必要があります。 参照元：Pearson VUE Additional Info AWS認定試験 - 受けたみた感想とハプニング 全体的な感想として オンラインで受けるAWS認定試験は、3回目の経験だったので、 ソリューションアーキテクトアソシエイトを受けた時よりもよりスムーズにかつ、全体的に落ち着いて進めることができました。 受かってものすごく嬉しいです！！✨ プロクター(試験官)の傾向 前回の試験官よりは軽めに部屋チェックをしてくれる人だったので、360°ビデオで部屋を2周するくらいでOKしてくれました（※前回は3周） ただ、天気が晴れていて明るかったのか、カーテンを閉めてくれという依頼があったので、レースのカーテンだけ閉めました。（流石に遮光カーテンはしめたくないw） パソコンのウェブカメラで直持ちして撮ってるので、曲芸師並みの角度から机の上に何もないことを証明するために、必死で撮影しました。 なかなか面倒だったw ソリューションアーキテクトアソシエイトとの比較 試験の言語は、自分は英語で受けました。 whizlabのデベロッパーアソシエイトの模擬問題の問題とほぼ同じ問題しか出てないやんこれってなって、かなりとっつきやすかったのと、落ち着きを取り戻しました！ whizlab様様です✨ ソリューションアーキテクトアソシエイトの時よりも、問題文が短くて、かつ一本釣りの問題が結構多かったです。 難易度の肌感で言うと、 ソリューションアーキテクトアソシエイト > デベロッパーアソシエイト ですね。 ソリューションアーキテクトの方は、やはり設計の概念なので、 「このパターンではこれだろう〜」って選択肢を選ぶ時も、実際にはさまざまな課題解決方法や設計も考えられ、「別にこの設計でも間違いじゃないけどな！」っていうところの判断の匙加減が難しかったのですが、 デベロッパーアソシエイトは、実装の時にどう設定するか？みたいなIf A, echo B ってな感じだったので、割と命題みたいな感じで問題を解くことができました。 試験中の気持ち 試験開始は少し緊張したけど、チェックイン時間で間延びしなかったせいか、割と落ち着いて試験を進められました。 開始から10分くらい経つともうバーストモードに変わり、爆速で問題が解けました。 ただ、1ヶ月に3つの資格を取るために勉強しまくってきたせいか、20問目あたりで、若干ガス欠にいたり、試験問題以外のことを考え始めたりしてしまって、若干集中力に欠く場面が多かったです。 なんとか、自分を鼓舞しながら、問題文と格闘しました！ 試験時間は160分間で（ESL +30の事前申請したので）、90分くらいで問題を解き終わり、残り30分は回答の見直しと修正をしました。（今回はほぼ修正なかった） なので試験時間は全部使いませんでした。 実際2時間程度で終わりました！ 試験開始時刻は10時45分でしたが、試験を配布されたのが、想定より早く、その分試験を早く実施することができました。10時30分くらいには開始してたかな〜 問題の傾向 DynamoDB, Lambda, Api Gateway, Elastic Beanstalk, Code Pipeline, Build, Deploy, IAM辺りが割とコアの問題で、IAM Roleがやたら出ていた印象です。 AWSのセキュリティって、ROLE,ROLE,ROLE！！！！って感じで、 Rock 'n' Roll!!! Roling Stones!!!状態でした！ 何言ってるかわかりません、 とにかく　ロール　でますw (ヤマザキ、春のパン祭り♪だったら、シール溜まりまくるなこれ、、、) 前々回チェックイン時にテンパったので極力ブラウザ上の何かを触らないことに徹する 前々回クラウドプラクティショナーを受けた時に、試験専用ブラウザがフリーズして、マックの矢印アイコンがずっとくるくるし続けるというプチハプニングが発生し、チェックイン時間中15分くらい何もできない状態が続きました。 onVUEアプリのブラウザ自体が、かなり重いらしく（重くしてる？）、想定されていないコマンドがなされると処理ができない仕様になっているっぽくて、かなり困った。(Macとの相性とかもあるのかな？？？) 試験官（プロクター）とチャットでやり取りするんだけど、そのチャットモーダルが画面の左過ぎる場所に出現して、 移動させたい気持ちで溢れるのですが、下手に移動したりするのはやめた方がいいですねえ。 触らない方がいいです。あれ移動させると、アイコンくるくるし始めます。 今回は、そのクレームが反映されたのか、試験問題が配布された後に、試験官とのやりとりは、チャットではなく、なんとジェスチャーに変わりました！！ 試験官：これから試験を配布します 自分：はい 試験官：問題のWelcomeページが表示されましたか？みられたら手で「?‍♂️○」を作ってください。 自分：(...なんと！！変わったw　と　思いつつ、両腕をあげて、ウッキーポーズしました) フリーズが起こらずにスムーズに試験に移行できました！！！ 試験中に表示されるレコーディングのタスクバーは試験開始直後に煩わしくないところに移動させておく 問題を解いてる最中に、「レコーディングされている自分が見えるタスクバー」みたいなのが画面センター上部にあって、前回、問題を読んでいる時に毎回自分の姿が目に写り、煩わしかったので、 試験開始直後に、それをドラッグして場所を移動させちゃいました。 大体そういうのを移動させるとフリーズ現象が起こるので、極力ダメージが少ないタイミングで、それを行いました。 無事に狙い通り、あまりフリーズも起きずに、煩わしさも解消され、試験に集中できました。 繊細なonVUEシステムから開放されたい人はやっぱり、 テストセンターに行って受けるのが一番かもしれないですね(⌒▽⌒) スコアは何点だ！？=> 916点でした！ とりあえず試験終了後にCongratulations, Passと言われたので、ホッとしてますが、 スコアが来るまでに、最大で5営業日かかるみたいです。 気長に待とうと思いまする( ´Д`)y━･〜〜 想定より点数がいっていた！ 100~1000点満点中、916点なので、計算すると 816/900 = 90.6点 つまり、59/65問正解　という結果になりました！ 自分が思っていた以上に良かったので、相当AWSの開発に関する基礎がついたんじゃないかなと思います♪ この一ヶ月、頑張った甲斐あったな〜〜✨✨✨ まとめ 次は、AWS認定SysOpsアドミニストレーターアソシエイトをとるぞ！ （本当はソリューションアーキテクトプロフェッショナル目指したい。） ＼＼\٩( 'ω' )و //／／ 以上、ありがとうございました！

初版: 2021年4月27日 著者: 橋本恭佑、Nguyen Ba Hung はじめに 機械学習モデルをビジネスへ適用するSEを対象として、Amazon SageMakerによって利用可能になる、機械学習モデル及びデータの傾向の監視技術を解説しています。今回の投稿では米国の電話会社の顧客解約予測を題材として、説明可能性の可視化とバイアス監視を実機検証した結果を紹介します。 投稿一覧 Amazon SageMakerで実現する機械学習モデルの監視技術 Amazon SageMakerで実現する機械学習モデルの精度可視化とデータ品質監視 Amazon SageMakerで実現する機械学習モデルの説明可能性可視化とバイアス監視・・・今回の投稿 データと実験(以前の投稿とほぼ同一の内容です) 顧客解約予測データセット 今回は、Kaggleで公開されている、米国の携帯電話会社の顧客解約予測データセットを用いて検証を行います。 この顧客解約予測データセットは、1つの目的変数と69の説明変数を持っています。説明変数には、顧客の所在地(文字列だが、One-hot encodingするため2値)、毎日の時間帯毎の通話量(数値)、国際通話プランの加入有無(2値)や通話時間(数値)を含みます。 本実験ではデータセットを学習用（2333レコード）、検証用（665レコード）と推論用（333レコード）の3つのデータセットに分割し、推論用のデータセットを説明変数と目的変数に切り離して、説明変数を推論用データ、目的変数を正解ラベルとして利用します。また分割の際は学習用のデータセットと推論用のデータセットの両方に14%ずつ解約する顧客のデータがあるようにデータセットを分けました。 ところで、元のデータセットはドリフトやバイアスを引き起こすデータを含みません。今回の実験では顧客の国際電話プランへの加入有無に着目し、バイアスがないことを確認できるか検証しました。 機械学習モデルの監視システム 今回はAWSの組み込みExtreme Gradient Boosting アルゴリズムを利用して学習した機械学習モデルをデプロイします。そして、この機械学習モデルに検証用データを送信して、モデルを監視します。今回実験に用いる機械学習モデルの監視システムの構成を図1に示します。図1の薄い赤で囲った範囲をSageMaker Studioを用いて起動・操作・閲覧できます。Model Monitor, Clarify, SageMaker Studioの紹介は以前の投稿を参照ください。 図1: システム構成図 説明性監視とバイアス監視は、Clarifyによる説明性監視ジョブとバイアス監視ジョブにより行われます。説明性監視ジョブとバイアス監視ジョブは同一のClarifyのためのインスタンス上(図1右の緑の直方体)で実行されます。Clarifyの説明性監視ジョブは、推論用データおよび推論結果から一定時間ごとにSHapley Additive exPlanations(SHAP)1を算出し、説明性レポートを作成してS3ストレージへ出力します。SHAPとは特定の特徴量が推論結果へ及ぼす影響を評価する指標であり、以前の投稿で示した説明性監視の技術の1つである、Model Inductionによるアプローチで広く利用されています。またClarifyのバイアス監視ジョブは、あらかじめ指定した説明変数に基づき、推論用データと推論結果を比較して偏りがないことを計算し、バイアスレポートを作成してS3ストレージへ出力します。 S3ストレージに出力した精度監視結果、統計値レポート、説明性レポート、バイアスレポートや、監視ジョブ等のソースコードはSageMaker Studioの統合された画面を利用して確認できます。 実験設定 図1に示したModel Monitorのインスタンス、SageMaker Studio Notebookインスタンス、Clarifyのインスタンスはm5.xlargeインスタンス(CPU:4x 3.1 GHz Intel XeonR Platinum 8175M with AVX-512、メモリ：16GiB)としました。推論用データは毎秒2件ずつ機械学習モデルへ入力しました。さらに監視は1時間毎に行い、機械学習モデルが算出した解約の確率が0.8以上の場合に「解約」と判定します。 実験結果と考察 説明可能性の可視化 SageMaker Clarifyを用いて説明性監視ジョブを1時間ごとに実行し、SHAP値のトップ10を算出しました。 SageMaker Studioを用いると、説明性監視ジョブの監視期間中の監視結果一覧を図2の様に可視化できます。図2の中央の緑色のテキストの「No Issues」は、特定の時刻の説明性監視ジョブが成功したことを示しています。同様に、図2の中央の赤色のテキストの「Failed」は、正解ラベルの不足やClarify用のインスタンスのCPU過負荷などにより特定の時刻の説明性監視ジョブが失敗したことを示しており、図2の中央の青色のテキストの「In Progress」は、特定の時刻の説明性監視ジョブが実行中であることを示しています。 図2 説明性監視ジョブの一覧 成功した1つ1つの説明性監視ジョブの算出結果は説明性レポートとしてS3ストレージに保存されます(図3のファイル例1)。図3のファイル例1はPDFとJupyter notebookの両方の形式で得られます。 図3 ファイル例1: ある時刻の説明性レポート(report.pdf) 図3に示した時刻ごとの説明性レポートを重ね合わせて、一定期間における説明変数の寄与度の推移を可視化することも可能です。図2の右側から監視期間を指定して右下の「Add chart」をクリックすると、図4の様に期間中のSHAPの値が大きい説明変数の上位10個を可視化できます。縦軸は説明変数であり、説明変数の横の矢印と数字は、推論期間中に説明変数のSHAPの値の順番が上下した変化を示しています。図4より、日中の通話時間（Day Mins）とカスタマーサービスの通話回数（CustServ Calls）は、顧客の解約を予測するための2つの最も重要な説明変数であり、この推論期間中に順番が変わらなかったことがわかります。一方で、顧客がメイン州在住であるか（State_ME）は18ランク上昇しています。この機能は次の利用方法があります。たとえば期間限定でメイン州の顧客に対する解約引き止め等を目的としたキャンペーンを行った場合に、キャンペーンの期間を指定して説明変数(顧客がメイン州在住であること)の重要性が急上昇したことを観察することで、キャンペーンの影響があったことを把握する材料となります。 図4 ある時間帯における説明変数の寄与度のランキングトップ10 バイアス監視 SageMaker Clarifyを利用してバイアス監視ジョブを1時間ごとに実行して、あらかじめ指定した説明変数(本実験では顧客の国際電話プランへの加入有無)に対する偏りを複数のバイアスメトリクス について算出しました。 SageMaker Studioを用いると、バイアス監視ジョブの監視期間中の監視結果一覧を図5の様に可視化できます。図5の緑色のテキストの「No Issues」は、特定の時刻のバイアス監視ジョブがエラーなく完了したことを示しています。 図5 バイアス監視ジョブの一覧 成功した1つ1つのバイアス監視ジョブの算出結果はバイアス監視レポートとしてS3ストレージに保存されます(図6のファイル例2)。図6のファイル例2はPDFとJupyter notebookの両方の形式で得られます。 図6 ファイル例2: 特定の時刻のバイアス監視レポート(report.pdf) 図6に示した時刻ごとのバイアス監視レポートを重ね合わせて、一定期間におけるバイアスメトリックの推移を可視化することも可能です。 図5の右側で監視期間・バイアスメトリック・しきい値を設定すると、指定した監視期間中におけるバイアスメトリックの推移と、バイアスとみなして警告する場合の時刻を図7の様に可視化できます。 図7はバイアスメトリックとして、国際電話プランを契約した顧客の解約予測の再現率と、国際電話プランを契約していない顧客の解約予測の再現率の差分を可視化した結果です。x軸が時刻、青色の凡例が国際電話プランに加入している顧客とそうでない顧客の再現率の差分、オレンジ色の凡例が再現率の差分のしきい値(図5で0.5と設定しました)を表しています。 図7 監視期間中の国際電話プラン有無におけるバイアスメトリック(再現率の差分)の推移 図7のグラフを利用することで、国際電話プラン加入有無に基づく再現率の差分を可視化できます。図7では再現率の差分(青色の凡例)が0.3前後で推移していることがわかります。また図7では再現率の差分(青色の凡例)が図5で設定した再現率の差分のしきい値(オレンジ色の凡例)である0.5を一度も下回らないため、警告は起こらないことがわかります。 考察 以前の投稿でSageMaker Model Monitorを利用して、学習用データからベースライン用統計と制約条件を算出し、推論用データの統計と比較することで、ドリフト監視が可能であることを確認しました。また今回の投稿で、SageMaker Clarifyを利用することで、推論期間中における機械学習モデルの各説明変数の重要性の遷移やバイアスの監視が可能であることを確認しました。この仕組みを利用することで、機械学習モデルを学習させるデータサイエンティストは、推論時の機械学習モデルのパフォーマンスを逐次監視し、機械学習モデルの調整や再学習を行うべきかをタイムリーに判断できます。また、機械学習モデルを業務へ適用するシステムエンジニアは、推論用データが変化したことを把握することで、データサイエンティストへ通知し顧客への対応を検討することが可能です。 一方で、SageMaker Model MonitorやSageMaker Clarifyはまだリリースされて間もない機能であり、ドリフト検知の手法や推論後の後処理に機能拡張に期待したい点があります。 まず、教師なしアプローチによるドリフト検知技術の実装についてです。以前の投稿で示した様に、ドリフト検知技術には教師ありアプローチと教師なしアプローチの2種類がありますが、SageMakerの監視技術で利用可能なのは、2021年1月現在、正解ラベルが必要な教師ありアプローチのみです。教師なしアプローチによるドリフト検知技術が実装されることで、より広範囲な機械学習モデルの監視にSageMakerの技術を活用できることが期待されます。 さらに、推論後の後処理機能の拡張もあります。バイアス監視にメトリクスの値を用いる場合に、しきい値だけでなく、メトリクスの上限と下限の両方を指定するユースケースもあると考えられますが、そのような機能は2021年1月現在サポートされていません。バイアス監視の後処理に、例えばNumPyやscikit-learnの様なモジュールを組み込むことで、サポートされる様になることを期待します。 おわりに 3回の投稿に分けて、米国の携帯電話会社の顧客解約予測を題材として、SageMaker Model MonitorとSageMaker Clarifyを利用した機械学習モデルの監視技術を検証しました。検証の結果、これらのサービスを統合して利用することで、利用開始後の機械学習モデルを継続的に監視して、機械学習モデルの調整や再学習を行うべきかタイムリーに判断できることを確認できました。 Lundberg, S.M. and Lee, S.I., 2017. A unified approach to interpreting model predictions. In?Advances in neural information processing systems?(pp. 4765-4774). ↩

出来事 先日誤って、AWSのアクセスキーをGithubにあげてしまいました。調べていくうちに、これはとんでもないことをしてしまったと思い、急いで対処しようとしましたが、焦りもあって何もできず。何かプロのエンジニアに電話か何かで対応してもらえるアプリはないか探していたところ、「ココナラ」というアプリを発見。急ぎ、エンジニアに対応してもらいました。 AWSアクセスキーをGitHubにあげてしまった時の対処方法 AWSアクセスキーを含むコミットを削除し、AWSアクセスキーを保存した履歴を削除することが適切な対処方法です。具体的には、Git rebase機能、又はGit commitのamendオプションを利用することで履歴を削除することが可能です。 ◆まず初めにやること AWSを無効化する。 AWSアクセスキーを無効化した場合は、セキュリティ上の問題は発生しませんのでご安心ください。AWSアクセスキー（恐らくIAM userのAccess KeyとAccess Secret Key）は、無効にしたりSecretを更新することで既存Credentialは使用不可となるためです。ですので、原理上アクセスキーをコードから削除したり履歴上から抹消しなくても、攻撃が発生することはありません。 …ただし、やはりCredentialがコード履歴に残っていることは印象が悪いため、削除したほうが良いですよね、、、 ◆どのように防ぐか 「ブランチ戦略」です。 ブランチの位置づけとして「main」はテスト・コードレビューが完了したコード、「その他（devなど）」は消えたりrebaseされたりする可能性のあるコードとして分けておきます。そうすることで、ミスしたPushでもリカバーできる簡易性を担保させることができます。 この手法は開発メンバーが増えていけばいくほど有効になってきます。 （勝手にコミットを結合したり消したりするのはマズイので…） ◆rebaseとamendの使い分け amendは、直前のコミットを修正することが可能でして、この方法を用いるのが一番簡単です。 ただし、この方法は「直前のコミットを修正したい」場合にのみ有効です。rebaseは、修正したいコミットをどこでも修正することが可能です。ただし、rebaseコマンド自体が様々な機能を持っているので、コマンドの使いやすさでは劣ります。 ◆amendで修正する手順 以下の手順で修正が可能となります。 1. ローカル環境のソースコードを修正 2. コマンド "git add ." を実行 3. コマンド "git commit --amend" を実行 4. 直前のコミットのコミットメッセージがエディタで表示されます 5. 必要に応じてコメントを修正し保存 6. git pushコマンドを再実行（既にPushしたコミットを上書きするため、-fオプションが必要）

ERROR: relation "activities" does not exist 結論、ユーザー名とスキーマ名を揃えると解決します。 1. Show search path. SHOW search_path; で確認してみると、 $user, public userがpublicになっているので、スキーマ名にする。 2. Set schema name. set search_path to schema_name; ref Appendix もしくはqueryでschemaを指定してもOK。 select * from schema_name.table_name;

こんにちは、まゆみです。 今回からAmazon Web Services (略して『AWS』と呼ばれる)の解説ブログをシリーズで書いていきます。 今回は第1回目になります。 実は私自身、AWSの勉強を始めるまで、クラウドサービスの中身をあまり理解していなかったのです。 新しい分野を始めて勉強するときには、『大局を知る』ということが重要でして、このシリーズでは ①まずクラウドサービス自体、何なのか？ ②Amazon社が提供するAWSってどんなものなの？ というざっくりした大局をつかむということを目的として書いていきます ではさっそく始めていきますね。 クラウドサービスとは？ クラウドサービスとは、一言で言えば『インターネット接続を利用して、他の場所にある誰かのコンピューターを使わせてもらうこと』です。 身近な例で言えば、Drop Boxや、iCloudなどが有名ですよね。 上記のサービスを使えば、あなたのパソコンではなく、他の違う場所にあるコンピューター内に、大事なドキュメントや画像・動画など保存させてもらうことができます。 仮にあなたのパソコンが物理的になくなったとしても、バックアップを取ることができるので安心です。 また、バックアップ機能だけではなく、あなたが持っている他のデバイス(スマホやタブレットなど)からもアクセスできるところも嬉しいところですね。 企業ではどのように活用できるの？ では次に、個人レベルでの活用法ではなく、企業にとってクラウドサービスはどのように役立てることができるのか見ていきましょう まず従来の情報システムの構築・運用形態『on premise(オンプレミス)』と比較することによって、クラウドがどんな優れた点があるのかを、書いていきます。 High Availability Available とは入手可能という意味です。 先ほど、説明したようにクラウドサービスを使えば、いつでもどこでもどのデバイスからでも、使いたいファイルにアクセスする事ができます Fault Tolerance Fault は障害や間違い、Tolerance は耐性を意味します。 クラウドの第2の特徴としては、バックアップが取れるため、障害に対する耐性があるということです。 自然災害や戦争などで物理的にあるデータセンターがダメージを受けたとしても大丈夫なように、他のところでバックアップを取ってデータを守っています。(Amazon社が、どのようにリスクヘッジをしているかは、『Region (リージョン)』や『Availability zone(アベイラビリティゾーン)』を解説するときに詳しく説明します) Scalability scalabilityはスケーラビリティと読みます。 『スケール』は日本語としても使うと思いますが、規模を表します。 例えば、あなたの開発したサービスが昨年に比べて大人気になり、アクセスする人が一気に増えたとしましょう。 その時に、on-premises では、その対応に時間がかかりますよね。 クラウドでは、規模が拡大した時に速やかに対応できる利点があります。 Elasticity elasticity は直訳すると『弾性』という意味になります。 ゴムのボールが縮んだり、膨らんだりできることを弾性があると言いますよね。 例えば先ほどの例とは逆のことが起こり、あなたの開発したサービスが翌年人気が落ちてしまったとしましょう。 ただ、あなたはサービスを開発した時に 「来年は、顧客倍増だぞっ！」と意気込んで、その強気予測に従って、設備投資をしてしまいました。 このような場合も、クラウドサービスを使っていれば、臨機応変に即時に規模を縮小させることができます Scalability は規模が増える場合のみ使われる言葉で、Elasticity は規模が増える時も、減る時もどちらの場合にも使われる言葉になります Amazon Web Services とは？ では、クラウドサービスにはたくさんの利点があることが分かったところで、AWSではどんなサービスを使うことができるのかを見ていきましょう AWSが提供するサービスは言葉で書くよりも、(多すぎて、むしろ言葉では書ききれません)実際コンソール内を見てみる方が早いと思うので、下のスクショを貼っておきます これが全てではありません。 スクロールバーでスクロールすると、まだまだ使えるサービスがあります。 AWSを使うにはどうしたら良いの？ AWSは無料で使える枠も提供してくれています。 この記事では登録方法などは割愛させていただきます。(すみません。<(_ _)>) AWSを実際使ってみるのが、一番の勉強になると思うので、是非登録方法をググって、使ってみてください。 下記に、AWSで頻繁に使うであろうサービスの説明をざっくり書いておきます。 VPCを作成する VPC と、『Virtual Personal Cloud』のことでして、Amazonの提供するAWS内に、あなた自身の仮想クラウドを作ることができます そしてこのVPC内にさまざまな機能をつけ足していきます EC2 EC2はAWSの最も大事なサービスの1つです。 EC2とは、ざっくりサーバーコンピューターだと認識しておきましょう EC2はインスタンスという単位で数えられます。 インスタンスと言われれば、「EC2のことを話しているんだな」と思ってくださいね。 RDS RDSはRelational Database Serviceの略になり、データベースを指しています。 SQLなどを勉強したことがある方なら、Relational Database という言葉は聞いたことがありますよね。(テーブル型のデータベース) NetflixはAWSの最大の顧客のようですが、Netflix社を例に取れば、顧客情報などが保存されているのが、RDSになります。 S3 ではNetflix社は自社の商品である、映画やドキュメンタリーを保存しているの？ それが、『S3』になります。 S3は、めちゃくちゃ大きいストレージバケットになります 情報の長期保存としても向いています EC2は、先ほど説明したScalabilityという点(データセンターを臨機応変に増やせるという点)では優れているのですが、それゆえ情報を失う可能性もはらんでいます。 まとめ 今回の記事はこれくらいで終わりにします。 今回は、AWSのイメージをつかんでもらいたく記事を書きました。 次回からは、もっと具体的な事に踏み込んで記事を書いていきますね。

忘備録！！！！ linuxにログインしてログを確認。 nginxのエラーログを確認する linux $ sudo tail -f /var/log/nginx/error.log Railsのエラーログを確認する。 linux $ sudo tail -f log/production.log エラーログのみ出力 linux $ tail -f ファイルパス | grep ERROR Heroku cloud9のコンソール $ heroku login -i $ heroku logs

AWSのリソースはCloud Formationを利用して、作成すると複製や削除が非常に楽になるので利用しているのですが、毎回「このリソースってどう書けばいいの・・・」っていうのが分からなくなるのでメモ書き。 AWS Cloud Formation って何？ テンプレート(yamlやjson)ファイルを利用して、AWS上に様々なリソースを作成できるサービス。 Cloud Formationのスタックにテンプレートを展開し、リソースを作成できる。 作成したテンプレートファイルがあれば同じリソースを作成することが可能なので、AWSコンソールを操作して作成という手間がなくなる。 あとスタックを削除するとそのテンプレートから作成されたリソースは全て削除されるため、不要になったリソースを削除するときに便利。 リソースの一覧 これが一番知りたかった。 やっと見つけました。 「AWS CloudFormation Resource types」と検索すると引っかかるようです。 テンプレートセクションの詳細 各セクションの説明はこちら。 よく使う組み込み関数 個人的によく使う組み込み関数を以下に記載します。 Ref パラメータの値を参照するときに使用する。 使用例： Value: !Ref SampleParameter Fn::Sub パラメータなどの値を文字列に埋め込んだりするときに使用する。 使用例： Description: !Sub '${EnvironmentName} sample' Name: !Sub - www.${Domain} - { Domain: !Ref RootDomainName }

AWSのリソースはCloud Formationを利用して、作成すると複製や削除が非常に楽になるので利用しているのですが、毎回「このリソースってどう書けばいいの・・・」っていうのが分からなくなるのでメモ書き。 AWS Cloud Formation って何？ テンプレート(yamlやjson)ファイルを利用して、AWS上に様々なリソースを作成できるサービス。 Cloud Formationのスタックにテンプレートを展開し、リソースを作成できる。 作成したテンプレートファイルがあれば同じリソースを作成することが可能なので、AWSコンソールを操作して作成という手間がなくなる。 あとスタックを削除するとそのテンプレートから作成されたリソースは全て削除されるため、不要になったリソースを削除するときに便利。 リソースの一覧 これが一番知りたかった。 やっと見つけました。 「AWS CloudFormation Resource types」と検索すると引っかかるようです。 テンプレートセクションの詳細 各セクションの説明はこちら。 依存関係のあるリソースを作成する場合 例えばリソースAはリソースBの作成後に作成しないとエラーになる場合、DependsOn 属性を使用することでリソースの作成の順番を指定できる。 よく使う組み込み関数 個人的によく使う組み込み関数を以下に記載します。 Ref パラメータの値を参照するときに使用する。 使用例： Value: !Ref SampleParameter Fn::Sub パラメータなどの値を文字列に埋め込んだりするときに使用する。 使用例： Description: !Sub '${EnvironmentName} sample' Name: !Sub - www.${Domain} - { Domain: !Ref RootDomainName }

AWSに関してこれから少しずつqiitaにまとめていこうと思う。 EC2とは Elastic Computed Cloud = EC2 EC2とは、クラウド環境で動作する仮想マシンを提供するサービスであり、サーバーやネットワーク機器などのハードウェアはAmazonで管理されている。このEC2は、仮想マシンを起動しているだけ費用がかかるという課金方式になっているので、最初に大きな初期投資をすることは必要がない。 基本時に、EC2を設置したら、このEC2インスタンスの管理者はインターネット上でEC２にリモートアクセスをしサーバーの設定を行うことが普通らしい。 EC2の料金 EC2には無料枠がある.勉強するときはこの無料枠を使うといい。 一定の条件を満たすと、月750時間までEC2インスタンスの利用が無料。 一定の条件とは、、、、以下 条件1 AWSのアカウントを作成してから12ヶ月以内であること。 条件2 無料対象枠のAMIを使用すること。 条件3 無料対象枠のインスタンスタイプを使用すること。 このような条件が存在する。 参考記事 Amazon EC2 の料金

現在のDocker環境は、docker-compose.yml達とLaravelを同梱している。 その為、Gitにプッシュしようと思ったら、丸ごと行ってしまう。 Laravelだけ、リポジトリ管理する事にした。 マシンスペック Mac mini 2018 macOS Catalina（10.15.x） Intel Core-i7 3.2GHz 6コア メモリ 32GB SSD 512GB Docker環境 Nginx 最新版 PHP（PHP-FPM）7.2.x MySQL 5.7.x Composer 1.x Laravel 5.6.x やること Laravelだけ、リポジトリ管理 前提 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その弐で環境構築済み Laravelだけ、Gitリポジトリ管理する 現在の構成 ディレクトリ構成は、こんな感じ。 [docker] ← クローンして来た |-docker-compose.yml |-.git |-... |-src |-laravel ← コイツだけリポジトリ管理したい！ |-app |-... .gitがdockerディレクトリ直下にあるので、プッシュすると丸ごと（dockerディレクトリごと）行ってしまう。 $ pwd /home/ec2-user/environment/docker $ ls -al ・・・ drwxrwxr-x 8 ec2-user ec2-user 198 Apr 20 10:34 .git ・・・ docker/src/laravelだけプッシュしたい。 リポジトリの向き先を変える 早い話、.gitがdockerではなく、docker/src/laravelにあれば良い。 やる事 Git初期設定 リポジトリを用意 docker/.gitを削除 docker/src/laravelをバックアップ（以下、旧Laravel） docker/srcにリポジトリをクローン（以下、新Laravel） 旧Laravelを新Laravelにコピー 旧Laravelを削除 新Laravelをプッシュ Git初期設定 未設定なら、やっておく。 $ git config --global user.name "GitHubユーザー名" $ git config --global user.email GitHubメールアドレス リポジトリを用意 空っぽなリポジトリだと、クローンした時にYou appear to have cloned an empty repository.って警告が表示されるので、おっ！？ってなる。 READMEだけ追加しておけば気にならなくて良い。 docker/.gitを削除 $ pwd /home/ec2-user/environment/docker $ rm -fdR .git docker/src/laravelをバックアップ（以下、旧Laravel） $ pwd /home/ec2-user/environment/docker $ cd src $ ls laravel $ mv laravel laravel_bak $ ls laravel_bak docker/srcにリポジトリをクローン（以下、新Laravel） $ git clone <上記でコピーしたリポジトリURL> laravel 例）git clone https://github.com/bobtabo/cloud9-laravel.git laravel Cloning into 'laravel'... remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done. $ ls laravel laravel_bak 旧Laravelを新Laravelにコピー $ ls -l drwxrwxr-x 3 ec2-user ec2-user 35 Apr 21 17:30 laravel drwxrwxr-x 13 ec2-user ec2-user 4096 Apr 19 17:40 laravel_bak $ cp -pR laravel_bak/. laravel $ ls -l drwxrwxr-x 14 ec2-user ec2-user 4096 Apr 19 17:40 laravel drwxrwxr-x 13 ec2-user ec2-user 4096 Apr 19 17:40 laravel_bak 旧Laravelを削除 $ ls laravel laravel_bak $ rm -fdR laravel_bak $ ls laravel 新Laravelをプッシュ ブラウザをリロードすれば、プッシュされている。 Cloud9を開き直す時 セッション切れなどでCloud9を開き直したら、ディレクトリ選択し直す。

問題 Railsアプリをconfig.force_ssl = trueでブラウザからhttpsアクセス出来る様にしたらALBのヘルスチェックが「unhealthy」となってしまう。 原因 httpからhttpsにリダイレクトさせる設定をしているので、 ヘルスチェックを行ったときにHTTPステータスコードで301が返って来るため。 config/environments/production.rb config.force_ssl = true 構成 以下の図の通りです。 対策 ロードバランサーでhttpからhttpsへリダイレクトするようにする。 NGINXの設定で対処方法もありますが、これが一番簡単そうなので。 手順 1.config.force_ssl = trueをコメントアウトする。 config/environments/production.rb # config.force_ssl = true 2.ロードバランサーのコンソール画面のリスナータブを選択し、HTTP:80の"ルールの表示/編集"を開く。 HTTP:80のリスナーを削除している場合は新たに追加して下さい。 3.＋タブを選択しルールの挿入を選択してルールを追加します。 4.すべての条件においてhttpからhttpsへリダイレクトさせたいので、パスの指定を*(アスタリスク)にします。 5.”アクションの追加”を選択してリダイレクト先を以下の通りに指定して保存ボタンを押してルールを追加します。 確認 httpでアクセスするとawselbによってhttps（４４３）にリダイレクトされるようになります。 $ curl -i http://www.xxxxxx.work HTTP/1.1 301 Moved Permanently Server: awselb/2.0 Date: Mon, 26 Apr 2021 16:05:10 GMT Content-Type: text/html Content-Length: 134 Connection: keep-alive Location: https://www.xxxxxx.work:446/ ALBのヘルスチェックもhealthyに変わっています。 参考