20211127のAWSに関する記事は14件です。

AWS Certified DevOps Engineer - Professional を取得した

前回のお話 はじめに 本記事は、将来再認定を受けるときの備忘録でもあります 本記事を見る時点で大体AWS認定試験のことや、DevOps Engineer - Professional のことはほかの記事のほうが詳しく書かれていると思うので、省略してまとめたいと思います 試験を受ける前の私のスペック AWS を使った業務経験は最低限はある EC2 関連がメインであり、その他機能についてはほぼ知らないに等しい状態 知識ベースの指標としては、AWS認定試験は以下を取得した アソシエイト資格3種 プロフェッショナル1種 ソリューションアーキテクトプロフェッショナル スペシャリティ 試験4種 データアナリティクス セキュリティ ネットワーク データベース 学習教材 AWS WEB 問題集で学習しよう ※ 模擬試験はやりませんでした 学習期間 11/1 - 11/27 AWS WEB 問題集で学習しよう(11/1 - 11/27) みんなの合格記を見る限り ♯1-56 の問題が満遍なく出てくると書かれていたので、1-56の問題を3週実施した 1周目 4-7割程度の正解率で満点比率は低め 2周目 7割-満点の正解率で満点は半々ぐらい 3週目 7割-満点の正解率で満点の比率は高め 問題の解き方は、間違えたor正解しているが運で正解したものはしっかり解説を読む アソシエイトレベルもしくはほかの試験で得た知識で答えれたものはスルーする形で実施した 1周目は約2週間掛けて実施した。2、3周目は1週間単位で実施した 試験結果 他の試験と比べると狭く深くという印象で、問題集で得た知識だけである程度は自信を持って解くことができた 試験自体は1周目で残り60分、見直しで残り15分と結構ギリギリでした。(試験中に別のことを考えたりしてて、試験に集中できてなかった+試験終盤は集中力が完全に切れていたのが要因ではある) 一通り解いて、2択ぐらいに絞り込むand全くわからない問題が15、16問ぐらいあった 点数的には予想通りより少し高い結果でした ポリシーと標準の自動化については弱いという結果だったので、精進しないとですね 試験を受けて思ったこと 一般的にはソリューションアーキテクトのほうが難しいという話題がWEBを徘徊する出回っている 個人的に思うのは、狭くそこそこ深い試験と、広く深そうな試験という点で、ソリューションアーキテクトのプロフェッショナルは後者 覚えることが多いのって結構しんどいし、実際に触ったことがない機能が試験範囲にいくつも含まれつつも、知識だけを頭に突っ込んで試験に挑むので、応用力が乏しくなるのは致し方がない部分があるのかもしれない DOP については、デプロイ方法や構成、障害復旧時の対応方法を求められるケースが多く、設問内に重要視している点が含まれているので、読み解いて適切な解を導き出す力が求められるように感じた そこで点が取れると6、7割は取れるように感じている 最後に 残すところMLSのみとなった 問題があるとすれば、AWSサービス以外に機械学習の知識が必要になるらしい そこのハードルがどれほどのものなんだろうか、、、 ブラックフライデーでUdemyの商材を買うか結構悩みどころですね
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

クラウドオーケストレーターのはじめかた

この記事は NTTドコモテクニカルジャーナル Vol.29 No.1 クラウドオーケストレータを活用した複数 Kubernetes 管理の筆者による解説記事です。この記事ではクラウドオーケストレーターを使いはじめるためのインストールとセットアップ方法を紹介します。 クラウドオーケストレーターとは クラウドオーケストレーターは、複数のクラウドを管理するためのワンストップポータルです。 CMS である Drupal をベースにオープンソースとして公開されているため、どなたでも利用することができます。 クラウドオーケストレーターを使うメリット クラウドオーケストレーターを使うと、AWS、Kubernetes、OpenStack、VMware、Terraform Cloud といったさまざまなクラウドを一元的に管理できます。 シングルサインオンや Azure AD(Active Directory)で既存のシステムに統合できます。 Kubernetes のリソースの使用状況を分析、最適化し、運用コストを削減します。 インストール クラウドオーケストレーターをインストールするには、いくつかの方法があります。 AWS Marketplace から EC2 インスタンスを起動 CloudFormation から AWS 上に起動 PHP Composer からローカルやオンプレの環境にインストール 以下、3つの方法をそれぞれ説明します。 AWS Marketplace から起動 いちばん簡単な方法です。AWS Marketplace の Cloud Orchestrator から起動してください。 AWS CloudFormation を使う方法 ビデオマニュアル CloudFormation でインストールする方法 をご覧ください。 EC2、ECR、S3、IAM の管理者権限のアカウントが必要です。 テンプレートを起動し、スタックが完了するまで数分待ちます。 クラウドオーケストレーターの自動セットアップスクリプトが実行されます(十数分かかります)。 進行状況をみるには、サーバーに SSH で接続しログを確認します。 スタック作成が完了したら、Drupal URL をクリックします。 以下の表から、利用環境に合った CloudFormation テンプレートを選択してください。 構成 Apache2 Memached MariaDB VPC CloudFormation テンプレート EC2+ElastiCache+RDS EC2 ElastiCache RDS 自動作成 cloud_orchestrator_full.yaml EC2+ElastiCache+RDS EC2 ElastiCache RDS 既存利用 cloud_orchestrator_full_manual_vpc.yam EC2 シングルインスタンス EC2 EC2 EC2 自動作成 cloud_orchestrator_single.yam EC2 シングルインスタンス EC2 EC2 EC2 既存利用 cloud_orchestrator_single_manual_vpc.yam EC2 シングルインスタンス Docker Docker Docker 自動作成 cloud_orchestrator_docker.yaml EC2 シングルインスタンス Docker Docker Docker 既存利用 cloud_orchestrator_docker_manual_vpc.yaml EC2 上の Docker+RDS Docker Docker RDS 既存利用 cloud_orchestrator_docker_rds_manual_vpc.yaml PHP Composer によるインストール ビデオマニュアル Composer でインストールする方法 をご覧ください。 はじめる前に、LAMP スタックと PHP の composer をあらかじめインストール・設定しておきます。 ターミナルを起動し、/var/www/cloud_orchestrator ディレクトリを作成・移動します。 mkdir /var/www/cloud_orchestratr && cd /var/www/cloud_orchestrator composer でクラウドオーケストレーターをインストールします。 composer create-project docomoinnovatins/cloud_orchestrator composer の実行終了後、ウェブブラウザーを開いて、サイトに移動します。 インストール手順に従ってサイトを設定します。 セットアップ ここでは、クラウドオーケストレーターで特に Kubernetes を管理するための設定方法を説明します。 Kubernetes の設定 アドミンユーザーを作成するための、以下の内容のマニフェストを作成します。 vi admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system マニフェストからアドミンユーザーを作成します。 kubectl apply -f admin-user.yaml 以下のコマンドを実行し、画面上に表示されるトークンを取得します。 export POD=$(kubectl -n kube-system get secret | grep admin-user-token | cut -f1 -d' ') && kubectl describe secret ${POD} --namespace kube-system クラウドオーケストレーターの設定 クラウドオーケストレーターにログインします。 Tour または Cloud service providers メニューから、K8s Cloud Service Provider を追加します。 API Server のフィールドにマスターノードの API エンドポイント URL、上で作成したアドミンユーザーのトークンを入力し、Save ボタンで保存します。 以下の画面が表示されれば成功です。 Cloud service providers メニューからクラスタを選択すると、各種リソースが確認できます。 複数の Kubernetes クラスターの管理 上記の手順にしたがって各クラスターのマスターノードの API エンドポイント URL とアドミンユーザーのトークンを取得、K8s Cloud Service Provider をそれぞれ追加することで複数の K8s クラスターをできます。 次のステップ クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

特定のサイトの更新情報をLINEに通知してくれるスクレイピングアプリを作ってみた!

はじめに 特定のサイトのお知らせ欄が更新されたかな?と毎回見に行くことって結構あるかと思うのですが、時にはやはり忘れてしまうものです。 サイト自体に通知機能のようなものがあればそれを利用するのも一つの対策ですが、そういうものがない場合は毎日確認することをルーチン化する!...いや...やはりそういうわけにはいきません。 そこで今回は特定のサイトのお知らせ欄を1日に2回見にいき、更新されていたらその記事をLINEで通知してくれる、というアプリを作ってみました。 完成形 LINE Notifyから毎日7:00と17:00に以下のように通知が来るようになっています。 記事が更新されていたとき 記事が更新されていないとき アプリ概要と構成図 Amazon EventBridgeが特定の時間になったらLambda関数を実行します。 Lambda関数は実行後、特定のサイトからお知らせ内容をスクレイピングし、LINE Notifyを通して特定のグループLINEへ結果を通知する作りとなっています。 EventBridgeとLambda関数はserverless.templateで管理しています。 アプリ構成図は以下です。 処理手順 簡潔ではありますがアプリの処理手順を以下に記載します。 ①特定サイトのお知らせ欄をスクレイピング 時間になるとAWS Event Bridgeがアプリを起動します。 起動したアプリが特定サイトへ行き、お知らせ欄をガバっと取得(※)します。 ※お知らせ欄は最新の記事10件程度しか掲載されていない作りになっていたので全取得するというロジックにしています。 ②①で取得したお知らせ一覧から通知していないものを絞り込み & 保存 AWS S3にCSVファイル形式で1度通知したお知らせを保管しており、①で取得したお知らせ一覧の中でCSVファイルに保管されていないものを絞り込みます。 絞り込まれたお知らせたちが今回の通知対象となります(今回通知対象のものがある場合はそのデータを新規にCSVファイルに書き込みます)。 ※保管方法についてはDBを利用したりその他色々あるかとは思いますが、DB使うと少し費用かかるかな?というのとこのアプリを作っている時期に業務にてCSV Helperという.NETのライブラリを久々に利用する予定だったのでそれの扱いを思い出しておこうという理由からこのような保管形式としました。 ③②で取得したお知らせをLineで通知 ②で取得したお知らせをLineで通知します。 それぞれの処理で使用したライブラリやサービスなど ①スクレイピング:AngleSharp 特定のサイトのお知らせ欄をスクレイピングする処理にはAngleSharpという.NET向けのライブラリを利用しました。 QuerySelectorやGetElementByIdなどJavaScriptでよく使うメソッドが利用できるので、特定のサイトの欲しい箇所を取得するのも結構楽にできました。 public async ValueTask<IHtmlCollection<IElement>> GetTopicDataAsync() { using var stream = await _clientFactory.CreateClient().GetStreamAsync(new Uri(_scrapingTargetsConfig.Url)); IHtmlDocument doc = await new HtmlParser().ParseDocumentAsync(stream); return doc.GetElementById("TopicId").QuerySelectorAll("table > tbody > tr"); } ②データ保存: AWSSDK.S3, AWSSDK.Extensions.NETCore.Setup, CSV Helper 当初はバッチ実行から1日前までの時間内のトピックのみ取得する、というロジックを組んでいたのですが、スクレイピング先のサイトのバグなのか、投稿日時が2日ほどずれており正常にトピックが取得できませんでした。 そこで、AWS S3へCSVファイルを保存し、そのCSVファイルに取得したものを保存し、そこにないもののみスクレイピングで取得していくというロジックへ変更しました。 CSVの操作については先ほど記載したCSV Helperを、ASP.NET CoreでS3の操作をする処理についてもAWSSDK.S3, AWSSDK.Extensions.NETCore.SetupパッケージをNugetから取得することで比較的楽に作成することができました。 public async ValueTask<GetObjectResponse> GetCsvFile() => await _amazonS3Client.GetObjectAsync(_awsConfig.S3.BacketName, _awsConfig.S3.Key); public async ValueTask UpdateCsvFile() { var putRequest = new PutObjectRequest { BucketName = _awsConfig.S3.BacketName, Key = _awsConfig.S3.Key, FilePath = _localStorageConfig.CsvPath }; await _amazonS3Client.PutObjectAsync(putRequest); } ③LINEでの通知処理: LINE Notify LINEへの送信についてはLINE Notifyというサービスを利用することで作成しました。 以下の記事にまとめましたが、とても良いサービスなので今後も似た処理を作る際は重宝しそうです。 (おまけ)インフラをコード化 こちらは以下の記事にまとめましたが、Visual StudioでServerlessプロジェクトを起動するとserverless.templateにてインフラ構成をJson形式で作成することができます。 EventBridgeなどもコード側で調整してサクッと反映させることができるのでとても良い感じでした。 おわりに 作った当初はLINEではなくメールで送信する感じだったり、AWS上にデプロイせずに自身のローカルPCのタスクスケジューラにセットしていたりと、今とは全然違う構成でした。 「こんな感じのほうが便利かな?」という感じでどんどん途中変更したり、前の現場の上司が(ありがたいことに)見てくださって「ここは〇〇したら面白そう!」みたいにアドバイスをくれたりという感じで実装が変わっていったのですが、それを通してたくさんの技術が学べてとても楽しかったです。 現在はこのLINE通知に任せっきりで、特に自分からサイトを確認しに行くことはなくなりました(笑) ちょっとしたことでも日々の面倒なことを解決するアプリを作ると生活も楽になりますし、技術的にも新しいことが学べるので今後も続けていきたいと思います!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ELB(Elastic Load Balancing)

【AWS ELB(Elastic Load Balancing)】 ELBは理解することが多くて大変。 ECS, Fargate, CodePipelineをCloudFormationで構築時、ALBの理解は必要不可欠。 主にALBを基本的なところから勉強し直しました。 なぜELB(Elastic Load Balancing)が必要?? 冗長化、可用性 高可用性:複数AZにある複数のターゲットの中から正常なターゲットにのみ振り分け可能 負荷分散、スケール スケーラブル:複数のEC2インスタンスやECSコンテナなどに負荷分散 ELB自体も負荷に応じてキャパシティを自動増減 ALBがスケールする時は、IPアドレスが変化する。 ELBヘアクセスするときには必ずDNS名でおこなう。 従量課金で利用可能 マネージドサービスなので管理が不要 AWSの他のリソースとの連携が可能 CloudFormation, Auto Scaling ...etc ELBの種類 ALB(Application Load Balancer) NLB(Network Load Balancer) CLB(Classic Load Balancer) ELBの使い方 VPC内、AZに設置 パブリックサブネットに指定する。 AZごとに1つのサブネットを指定 可用性を高めるに、2つ以上のAZからサブネットを指定する。 ICMP Echo Request/Replyを許可すれば、pingにも応答する。 ALBには、セキュリティグループの指定が可能 ALB(ELB)の用語 リスナー クライアントからの処理を受ける機能 トラフィックを受け付けるプロトコル(HTTP, HTTPSなど)とポート番号(1~65535)を設定 トラフィックをターゲットグループへの接続用のプロトコルとポート番号などを設定 ターゲット トラフィックを転送するEC2インスタンスなどのリソースやエンドポイント ターゲットの種類 IPアドレス インスタンスID Lambda関数 ターゲットグループ EC2インスタンスなどのターゲットの集合 ターゲットグループ内でリクエストは負荷分散される。 インスタンス側:インスタンスで公開するポート、プロトコル、設定を含む。 ※ ALBが使えなくなった場合、ターゲットグループを確認  → ヘルスチェックステータスを確認しよう。 ALBの高可用性と負荷分散ゾーンごとのフェイルオーバー 2段階での負荷分散 DNSラウンドロビンで各AZ内のELB(ロードバランサーノード)に振り分け 負荷が均等になるようにバックエンドへのルーティングアルゴリズムで振り分け ALB:ラウンドロビンルーティング ALBはクロスゾーン負荷分散がデフォルトで有効になっている。 リージョン内の複数AZに負荷分散が可能 複数リージョンへの負荷分散にはRoute53を併用できる。 AZごとにEC2インスタンスなどの数が違っていても、負荷を均等にできる。 ALBは同一インスタンスで複数ポートに負荷分散可能 同一インスタンス上で複数のコンテナサーバーを運用する時に有用 ECSを利用する場合は、動的ポートマッピング機能を利用できる。 ECSのタスク(サービス)をターゲットグループに登録することで、各タスクに対して負荷分散 各タスクに割り振られたECSクラスタ上のポートをターゲットグループに自動的に登録 ALB(ELB)のモニタリングログ ヘルスチェック 正常なターゲットにのみトラフィックをルーティング 設定値に基づき、ターゲットに対してヘルスチェックを定期的に行い、正常なターゲットかを判定 正常判定が厳しすぎると、インスタンスが使えるまでに時間がかかる 異常判定が厳しすぎても、過負荷時に処理できるインスタンスを減らしてしまうことになる ヘルスチェック設定 プロトコル(HealthCheckProtocol) ターゲットでヘルスチェックを実行するときに使用 Status200が返るのを確認(成功) ポート(HealthCheckPort) ヘルスチェックを実行するときに使用 パス(HealthCheckPath) ヘルスチェックの送信先であるpingパス デフォルトは、/ タイムアウト時間 ヘルスチェックを失敗と見なす、 ターゲットからレスポンスがない時間 2〜120秒 正常のしきい値(HealthyThresholdCount) 異常なターゲットが正常と見なされるまでに必要なヘルスチェックの連続成功回数 非正常のしきい値(UnhealthyThresholdCount) ターゲットが異常と見なされるまでに必要なヘルスチェックの連続失敗回数 間隔 個々のターゲットのヘルスチェックの概算間隔 CloudWatchによって、メトリクスを60秒間隔で監視可能 最短5分間隔でアクセスログを取得可能  → 指定してS3バケットへ簡単にログを自動保管 ALB(ELB)のコネクション 無通信状態が続くとそのコネクションを自動で切断する ALBは、デフォルトではコネクションタイムアウト値は60秒 ALBのコネクションタイムアウト値は変更可能 1〜4000秒の間で設定可能 Connection Draining(登録解除の遅延) デフォルトで有効 タイムアウト300秒 スティッキーセッション 同じユーザから来たリクエストを全て同じEC2インスタンスなどに送信 デフォルトで無効 アプリケーションでのセッション情報、一時ファイルなどを保持する構成に必要 HTTP/HTTPSでのみ利用可能 ※ EC2インスタンスなどの増減を柔軟にできるように、セッション情報などは別のDBサーバやキャッシュサーバに持たせるのが望ましい  → スティッキーセッションは不要になる。 ALB(ELB)のセキュリティ SSL/TLSターミネーション ALB(ELB)側でSSL/TLS認証(基本的にはTLSプロトコルを使用) ALB(ELB)にTLSサーバ証明書をアタッチすることで、通信の暗号化・複合を担ってくれる。 ACM(AWS Certificate Manager)で作成すれば、無料利用可能 ACMと統合されているELB, CloudFront, API Gatewayのみ。 証明書のリクエスト、管理、更新、プロビジョニングが容易に実行可能 証明書は自動更新、失効の心配がない。 ALBの特徴!! L7ロードバランサー コンテンツベースのルーティング(高度なリクエストルーティング) パスベースのルーティング リクエストURLのパスパターンに基づいたルーティング パス部分のパターンでターゲットグループに振り分ける。 ホストベースのルーティング HTTPヘッダーのHostフィールドに基づいてクライアントのリクエストをルーティング 同一のロードバランサーから複数のドメインへのルーティングが可能 ホスト名のパターンでターゲットグループに振り分ける。 HTTPヘッダーベースのルーティング 各リクエストのHTTPヘッダーに基づいたルーティング 例)Version1用のサーバーとVersion2用のサーバーに振り分ける。 HTTPメソッドベースのルーティング 標準またはカスタムのHTTPメソッドに基づいてクライアントのリクエストをルーティング クエリ文字列パラメータベースのルーティング キーと値のペアまたはクエリストリングの値に基づいたルーティング 例)Chrome用サーバーとSafari用サーバーに振り分ける。 送信元IPアドレスCIDRベースのルーティング リクエスト元のソースIPアドレスCIDRに基づいてクライアントのリクエストをルーティング ALBとAWS WAFの連携 以下の条件を利用して、ALBを保護可能 リクエストレートによるアクセス権限 特定のIPアドレスや地域からのアクセスを制限 クロスサイトスクリプティングやSQLインジェクションから保護 HTTPヘッダー、HTTP本文、URI文字列に対するサイズ制約や正規表現でのマッチング 参考 CloudTech 【AWS Black Belt Online Seminar】Elastic Load Balancing (ELB) おわりに。 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com 過去記事 AWS ELB(ALB, NLB)の違い 転職活動中にロードバランサーについて聞かれて、こんなものを書いていた。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ETL処理を用いて、デイトレードの取引データを加工→蓄積する流れのまとめ

概要 データ分析のインターンのおかげでETL処理を組むことができるようになりました。 今回はこの技術を用いて、為替のデイトレードで得た取引履歴の、データ加工と蓄積の流れを構築したいと思います。 できるようになること AWSでETL処理が書けるようになる データストレージの使い方が少しわかる 補足 今回はGlueやLambdaを用いない、データ分析の半自動化を目指しています。とはいえ、スクリプトさえできてしまえば自動化も簡単なので別記事でその方法を書こうと思います。 利用サービス AWS S3 Amazon SageMaker HighLow Australia (証券会社) ETL処理フロー データフローの全体像はこちらです。 S3のDataLakeというバケットに溜まった取引履歴をデータ整形して、DataWarehouseに蓄積します。(HighLow側にAPIがないので、DataLakeへのデータ蓄積は手動アップロードにします。) ETL処理の前準備 ETL(抽出、変換、読み込み)処理を行う前に、そもそも抽出するデータがストレージに蓄積されていないといけません。本来のAWSのS3活用方法とは異なりますが、今回は気にせずデータのアップロードを手動で行います。 データ取得 HighLowオーストラリアという証券会社の、個人的な取引履歴を利用します。 写真の様に、[検索する]から数字の順番に取引履歴取得範囲を設定し、[ダウンロード]でCSV形式でダウンロードします。 取引データの配布等は行っていませんのでご了承ください。 分析頻度は週単位想定しているので、とりあえず1ヵ月を4週間に分けて4つのCSVファイルを取得しました。 S3へデータアップロード AWSのS3では、 - datalake-trading - datawarehouse-trading というバケットを用意しておいてください。 ここの、datalake-tradingというバケットに、[trading-history/]というプレフィックスを切り、その中に先ほど取得したCSVファイルをアップロードします。 SageMakerでETL処理を書く データの準備ができたことで、いよいよデータ中身を見ながら整形していきます。 コーディング環境の作成 AWSのSageMakerを開いて、ノートブックインスタンスを作成してください。 個人利用なので、インスタンスタイプはデフォルト最小の[ml.t2.medium]で十分だと思います。 ここからは作成したインスタンス上で、JupyterLabを利用してコーディングしていきます。 S3のデータを受け取るpythonスクリプト JupyterLab上で、Python3を書いていきます。 ライブラリダウンロード データ整形する対象のファイル名をS3から取得 対象のファイルをS3から取得しデータフレームとして読み込み この流れでスクリプトを書きます。 なお、CSVファイルには日本語が含まれているので、encoding='Shift-jis"という引数を与えないと、データフレームとして読み込むことができませんので注意が必要です。 import pandas import boto3 import io s3_client = boto3.client('s3') data_bucket_name='datalake-trading' obj_list=s3_client.list_objects(Bucket=data_bucket_name) file=[] for contents in obj_list['Contents']: if "csv" in contents['Key']: file.append(contents['Key']) else: print("Not CSV:", contents['Key']) file_data=file[-1] # 最新ファイルの取得 print("Target CSV:", file_data) response = s3_client.get_object(Bucket=data_bucket_name, Key=file_data) response_body = response["Body"].read() temp_df = pandas.read_csv(io.BytesIO(response_body), header=0, delimiter=",", low_memory=False,encoding="shift-jis") スクリプトは今後の自動化を想定して、最新ファイルのデータ整形を行う仕様にしています。過去データをすべて取得する場合は、データフレームを週ごとに読み込んで結合する処理が別途必要です。 ちなみにs3へのアクセスモジュールはこちらを参考にしました。 データフレームを見る データ分析の第一歩です。生データを目視して、分析に必要そうなデータを新たに作成したり、逆に不必要なデータを取り除いたりします。 個人的に分析したい内容は、 証拠金増減の時系列グラフ 各通貨の勝率 手法別での勝率 High-Low別の勝率 です。もっと見たいところはあるけど一旦はこんな感じにします。 なので、これを満たすようなデータフレームを作成するところが目標です。 データ整形のpythonスクリプト 特徴量を作っていきます。 # 列名を英語表記に変える temp_df.rename(columns={'取引番号':"trading_number", '取引原資産':'currency', 'オプションの種類':'option_type', '方向':'HighLow', ' 取引内容 ':'entry_point', 'ステータス ':'states', '購入':'Bet_amount', 'ペイアウト ':'payout', '判定レート ':'end_point', ' 取引時間 ':'entry_start', ' 終了時刻 ':'entry_end'}, inplace=True) temp_df['Bet_amount'] = [int(Bet_amount.replace("¥", "").replace(",", "")) for Bet_amount in temp_df['Bet_amount']] temp_df['payout'] = [int(payout.replace("---", "0")) if payout=="---" else int(payout.replace("¥", "").replace(",", "")) for payout in temp_df['payout'] ] temp_df = temp_df.sort_values(['trading_number']).reset_index(drop=True) #日付の昇順に並び替え # 1. 証拠金増減の時系列グラフに必要なデータ temp_df['deposit'] = 0 for i in range(len(temp_df)): mergin = temp_df['payout'][i] - temp_df['Bet_amount'][i] if i != 0: temp_df['deposit'][i] = temp_df['deposit'][i-1] + mergin else: temp_df['deposit'][i] = 0 # 2. 各通貨の手法別の利益を出すのに必要なデータ temp_df['total_check'] = [int(p-b) if p>b else p for (b, p) in zip(temp_df['Bet_amount'], temp_df['payout'])] # 3. 勝率計算に必要なデータ temp_df['win_lose'] = ["win" if check!=0 else "lose" for check in temp_df['total_check']] # 4. 平均獲得Pipsを計算するのに必要なデータ temp_df['pips'] = [(e - s) if e>s else (s-e) for (e,s) in zip(temp_df['end_point'], temp_df['entry_point'])] datawarehouseへデータを送る ファイル名を指定して、datawarehouseに整形後のCSVファイルをアップロードします。 # 取引期間の取得 start_date = temp_df["entry_start"][0].split(" ")[0].replace("/", "-") last_date = temp_df["entry_end"][len(temp_df)-1].split(" ")[0].replace("/", "-") # 保存するファイル名 file_name = start_date+"_"+last_date+".csv" # csvファイルの作成 temp_df.to_csv(file_name) # datawarehouseアップロード s3 = boto3.resource('s3') upload_bucket = s3.Bucket(upload_bucket_name) upload_bucket.upload_file(file_name, file_name) 上記を実行し、S3:datawarehouse-tradingを確認します。 確かに、アップロードされていることを確認しました。 自動化する場合は、この記事で書いたコードを、AWS Glueに張り付けるだけです。 次回は、Glueで自動化 → BIツールで可視化する流れを書こうと思います。 最後に Sagamakerのインスタンスは稼働時間に対してお金がかかります。 使わない時はインスタンスを停止しておくよう注意しましょう。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSなんもわからん人におすすめ!!!

Volare Advent Calendar 22日目担当のみっきーです。 実は,今日(12月22日)はわたしの誕生日です!? お祝いのLGTMお待ちしています笑 この記事の対象者 本当の本当にAWS触ったことない人 AWSにこれから入門したい人 AWSクラウドプラクティショナー認定試験の受験を考えている人 おすすめの教材 本題です! おすすめの教材とは、Udemyの講座?書籍?ではないです。 AWSが公式で無料で提供しているトレーニングがめちゃくちゃわかりやすくておすすめです!!!!!!! 今回お勧めしたいトレーニングは、AWS Cloud Practitioner Essentials (Japanese) (日本語実写版)です。 日本語字幕付きのコーヒーショップのかわいいアニメーション動画と共に学んでいきます。 特に、EBSとS3のバトルシーンは必見です。 最後にチェックテストもあり、理解度をはかることができます。 コースの説明 このコースは、特定の技術領域ではなく、アマゾン ウェブ サービス (AWS) クラウドを全体的に理解したい方を対象としています。受講者は、AWS クラウドの概念、AWS のサービス、セキュリティ、アーキテクチャ、料金、サポートについて学習し、AWS クラウドについての知識を深めます。このコースは、AWS 認定クラウドプラクティショナー試験の準備にも役立ちます。- コースレベル: 基礎- 所要時間: 6 時間 所要時間6時間とありますが、チェックテストを読み込んだり、動画を見返したりしていたので、わたしは6時間以上かかりました。 学んだこと AWSのサービスの特徴について。 EC2、データベースやストレージなど使い方や利点などを説明してくれています!コースの概要をみていただくとわかるのですが、よく使うようなAWSのサービスを広く浅く紹介してくれています。 嬉しいポイントとしては、似たサービスの使い分けのシーンを具体的に教えてくれるところです。 AWSクラウドプラクティショナーの出題範囲の雰囲気。 また、コースの概要は以下の通りになっていて、かなりボリュームがあります。 コースの概要 モジュール 1: アマゾン ウェブ サービスの紹介 モジュール 2: クラウドでのコンピューティング モジュール 3: グローバルインフラストラクチャと信頼性 モジュール 4: ネットワーク モジュール 5: ストレージとデータベース モジュール 6: セキュリティ モジュール 7: モニタリングと分析 モジュール 8: 料金とサポート モジュール 9: 移行とイノベーション モジュール 10: クラウドジャーニー モジュール 11: AWS 認定クラウドプラクティショナーの基本 コース修了時の認定テスト 嬉しい特典 無事にトレーニングを完走すると名前入りの認定証がもらえます。(ここでは名前は消してます) 嬉しいですね おわりに この動画の後は、他のトレーニングを受けたり、ブラックベルトを読んだりして知識を増やしたりしていくと良いと思います。他のトレーニングでは、ハンズオンもあったと思います。 おすすめのトレーニングが他にありましたら是非教えてください! 最後までご覧いただきありがとうございました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amplify で Slack アプリつくってみた

はじめに この記事は、「 AWS Amplify Advent Calendar 2021 」4日目の記事です。 こんにちは。 Amplify でプロダクトを開発しているスタートアップに参画させていただいて半年ほど経ちました。 Amplify とチームの皆さんのおかげで日々良きサーバレス開発を送れています。 その中で Amplify を使って Slack アプリをつくったので、そのお話を共有させていただきます。 前提条件 私の場合、 Slack アプリを開発するにあたり、以下の要素を考慮する必要がありました。 開発のメインツールが Amplify のため Amplify 上で Slack アプリを実現したい Slack アプリも Amplify の multi env に対応させて環境ごとのリソースを参照したい Slack アプリのインフラコストを抑えるために サーバレス (FaaS) で実現したい そもそも Slack アプリのようなコミュニケーションツールのアプリ (ボット) をつくるのは初めて 検討 まず、 Slack アプリをどのように作成するのか調査しました。 Slack アプリには Bolt というフレームワークがあり、こちらを用いることで非常に簡単にアプリをつくることができました。 また、 Serverless Express と組み合わせることで、 Lambda にもデプロイできることがわかりました。 Lambda に載せることができれば、 Amplify で全て管理できると判断しました。 この時点では、1つの Lambda 関数で Amplify リソースの操作もできる Slack アプリがつくれると思っていました。。。 しかし、それは実現できませんでした。 なぜなら、 Slack には Slack API に対して3秒以内に返答しなければならないという制約があります。 (参考: https://api.slack.com/interactivity/handling) つまり、 Slack API から Slack ワークスペースの操作を受け取った Lambda で Amplify リソース操作 (AppSync, DynamoDB オペレーションなど)を実行していると3秒のタイムアウトが発生してしまいます。 困りました。。。。 構成 検討し、最終的に以下の構成で Slack アプリを作りました。 ①の赤枠が Slack からの Amplify プロジェクト内の Slack アプリ呼び出し ②の青枠が Amplify プロジェクト起点の Slack アプリ動作 です。 ① Slack からの Amplify プロジェクト内の Slack アプリ呼び出し (赤枠) Slack API に3秒以内に応答するために Slack API からのリクエスト受信・返答の Lambda 関数、ビジネスロジックを実行する Lambda 関数を分割しました。 Slack ワークスペースのイベント (メッセージの投稿やスラッシュコマンド) を受け取るための API Gateway と受け取ったリクエストを処理するための Lambda 関数を amplify add api コマンドで追加しました。 API Gateway に紐づく Lambda 関数は、 Slack Bolt で実装しました。 Slack のイベント毎の処理を記述しやすく、機能別 (例えば Slack アプリのインストールページ) の URL パスも設定済みです。 ビジネスロジックは API Gateway に紐づく Lambda 関数 (Slack Bolt) ではなく、別の Lambda 関数で実装します。 これらのビジネスロジックを含む Lambda 関数は Lambda 関数 (Slack Bolt) から呼び出されます。 Lambda 関数 (Slack Bolt) はビジネスロジックを含む Lambda 関数を呼び出したのち、直ちに Slack API に応答レスポンスを返します。 呼び出された Lambda 関数では Amplify プロジェクトリソースにアクセスした結果をもとに Slack API へリクエストを実施することができます。 // API Gateway に紐づく Lambda 関数 Slack Bolt 実装サンプル (TypeScript) import { LambdaClient, InvokeCommand } from "@aws-sdk/client-lambda"; import { App, ExpressReceiver } from "@slack/bolt"; import serverlessExpress from "@vendia/serverless-express"; const expressReceiver = new ExpressReceiver({ signingSecret: process.env["SLACK_SIGNING_SECRET"], // Lambda 環境変数から取得 clientId: process.env["SLACK_CLIENT_ID"], // Lambda 環境変数から取得 clientSecret: process.env["SLACK_CLIENT_SECRET"], // Lambda 環境変数から取得 installationStore: { // DynamoDB による Slack ワークスペースごとのトークン処理を実施 }, }); // カスタムレシーバーを用いた Bolt アプリの初期化 const app = new App({ receiver: expressReceiver, }); // 別 Lambda 関数を呼び出すために必要な Lambda クライアント const lambdaClient = new LambdaClient({ region: process.env["REGION"] }); // スラッシュコマンドのリスナー app.command("/foo", async ({ body, ack }) => { const command = new InvokeCommand({ // amplify cli にて別 Lambda 関数の呼び出し権限を付与済み FunctionName: process.env["FUNCTION_FOOCOMMAND_NAME"], InvocationType: "Event", Payload: new TextEncoder().encode(JSON.stringify(body)), }); await lambdaClient.send(command); // 本処理を実装した Lambda 関数を呼び出す await ack(); // Slack API サーバに応答する }); export const handler = serverlessExpress({ app: expressReceiver.app, }); ② Amplify プロジェクト 起点の Slack アプリ動作 (青枠) AppSync リゾルバによる Lambda 関数の呼び出しや DynamoDB Streams をトリガーとする Lambda 関数内で Slack API へリクエストを投げることで、 Amplify プロジェクトの通知を Slack チャンネルに飛ばすこともできます。 この形式では、もちろん Slack API のタイムアウトを気にする必要はありません。 // DynamoDB Streams で起動する Lambda から Slack API へリクエストを投げるサンプル (TypeScript) import { WebClient } from "@slack/web-api"; export const handler = async (event: Event): Promise<StreamsEventResponse> => { // 省略 // 永続層などから Slack Bot トークンを取得 const token = getToken(); // Slack Web API クライアントの初期化 const slackWebClient = new WebClient(token); // Slack へメッセージの投稿 await slackWebClient.chat.postMessage(); // 省略 }; 改善したい点 Lambda から Lambda 呼び出し問題 Slack API の3秒制限を回避するために、 Lambda から別の Lambda を呼び出しています。これはアンチパターンのコード内ではオーケストレーションしないに少なからず、当てはまってそうな気がしています。(SQS などを挟んだ方が良さそうだと感じています...) Identity 問題 現在、 Slack ユーザと Amplify プロジェクトのユーザ (Cognito) の紐付けは メールアドレスベースで実装しています。できるのであれば OIDC で Slack ユーザと Cognito ユーザの紐付けができると良さそうだと感じています。 知識不足だったりで、よくわかってないところがあるので、上記、間違い指摘・アドバイスいただけたら嬉しいです! おわりに このやり方がベストというわけではないと思いますが、 Amplify のみで Slack アプリをつくれたことはかなりメリットでした。 Slack API の3秒制限は Lambda のコールドスタートという特性がデメリットになります。 これを回避するために、 Fargate ベースの API を Amplify で構築するという手段もありますが、コストの観点からやはり Lambda だけで実現できたのは嬉しいことでした。 Amplify によってクラウドリソースの抽象度が高いおかげで、気軽に色々トライできる環境は非常にありがたいです。 Amplify の進化をキャッチアップし続けていきたいですし、他の AWS サービスにも精通できたらいいなぁなんて思ってます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSLambda(Golang)×DynamoDBのローカル開発環境を整える

目的 AWS LambdaでバックエンドAPIを構築しているとき、関数の挙動を確認したいときは都度devにデプロイしていました。流石にローカルでの開発環境を整えたいと思ったのですがGoでの使い方の情報が少なかったので個人メモとしてまとめてみました。 今回はAPI GatewayがトリガーのLambda関数になります。 →serverless invoke local -f <function> で十分らしいです 全体の流れ 以下のJavascript filesのところを今回はGolangにしてやってみます。 引用:https://qiita.com/noralife/items/e36621ddd0e5b8ff4447#%E6%A7%8B%E6%88%90 大まかな流れは以下です。 1. DynamoDB Localをインストール&セットアップ 2. Serverless offlineをインストール &セットアップ DynamoDB Localをインストール&セットアップ パッケージインストール $ npm install --save-dev serverless-dynamodb-local serverless.ymlにプラグインを追記 serverless.yml plugins: - serverless-dynamodb-local JDKがなければここでインストール dynamodb-localのためにはJavaが必要でしたので、ローカルpcにJavaを入れていない方はインストールします。 インストールの仕方は、mac osだと、以下が参考になります。 https://qiita.com/suke_masa/items/f9af0fb84ad9447ae961 dynamo db localをインストール serverless.ymlのあるディレクトリにて、 $ sls dynamodb install カスタム定義 serverless.yml custom: dynamodb: stages: - dev start: port: 8000 inMemory: true migrate: true seed: true seed: development: sources: - table: テーブル名 この状態で、 sls dynamodb start でdynamodbがローカルで立ち上がります。 http://localhost:8000/shell にアクセスすると管理画面に移れる。 シェル例 var params = { TableName: 'pr_enqueteform_dev', }; dynamodb.scan(params, function(err, data) { if (err) ppJson(err); else ppJson(data); }); Serverless offlineをインストール &セットアップ 次にローカルでapi gatewayを試すためにServerless offlineをインストールしていきます。 パッケージインストール $ npm install --save-dev serverless-offline serverless.ymlにプラグインを追記 serverless.yml plugins: - serverless-dynamodb-local - serverless-offline ### 追記 カスタム定義 serverless.yml custom: serverless-offline: useDocker: true この状態で npx sls offline でローカルで起動できます。 ※Makefileにて、 make local-test を打つことでビルド〜offline起動までやってくれるようにしています。 例: $ npx sls offline Serverless: Deprecation warning: CLI options definitions were upgraded with <中略> ┌───────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ POST | http://localhost:3000/dev/submit │ │ POST | http://localhost:3000/2015-03-31/functions/EnqueteformReceiver/invocations │ │ │ └───────────────────────────────────────────────────────────────────────────────────────┘ offline: [HTTP] server ready: http://localhost:3000 ? offline: offline: Enter "rp" to replay the last request offline: POST /dev/submit (λ: EnqueteformReceiver) 上記みたいな感じになっていたら立ち上がっています? offlineとdynamodb-localを疎通させる localでofflineを使ってlambda apiを叩いてログを出力してみると、 handlerのeventsの中の、 events.APIGatewayProxyRequest.RequestContext.APIID が "offlineContext_apiId" となっていました。 そこで、この部分で判断して、localのdynamodbクライアントを生成するか本番用のdynamodbクライアントを生成するかを条件分岐させることにします。 localのdynamodbクライアントの生成方法は以下でやります。 func (c *DynamoDBClient) OfflineDynamoDBClient(region string, tableName string) *DynamoDBClient { sess := session.Must(session.NewSession()) config := aws.Config{ Region: aws.String(region), Endpoint: aws.String("http://host.docker.internal:8000"), DisableSSL: aws.Bool(true), Credentials: credentials.NewStaticCredentials("dummy", "dummy", "dummy"), } dynamodbClient := DynamoDBClient{ tableName: tableName, dynamo: dynamodb.New(sess, &config), } return &dynamodbClient } ※もっとよい判定方法がありそうな感じです。 試してみる ローカルでコードを編集した後、一度ビルドしなければローカルの方にも反映されませんので、 make clean make build npx sls offline とします。 curlで疎通してみる sls offlineしたターミナルとは別のタブにて、 curl http://localhost:3000/dev/submit -X POST -H "Content-Type: application/json" -d '{"category":"hogecategory","email":"sample@gmail.com","address":"東京都", "hoge":{"id":"1001","text":"hogehoge"}}' sls offlineしたターミナルのタブにてログが出てくる。 START RequestId: d09*7296d-***-1c72-545b-5**c58d99034 Version: $LATEST <中略> END RequestId: d09729?6d-b4e2-1c72-5*45b-5e**ec58d99034 REPORT RequestId: d09?7296d-*b4e2-1c72-545b-5c5*d99034 Init Duration: 189.68 ms Duration: 5513.25 ms Billed Duration: 5514 ms Memory Size: 3008 MB Max Memory Used: 34 MB 実際にローカルのdynamoDBにデータを挿入する関数であれば、 http://localhost:8000/shell をみてみると挿入されていることが確認できます! 参考 Serverless Framework での AWS Lambda + Go ローカル開発事情 Serverless アプリケーションをローカルで開発する serverless framework + TypeScript +DynamoDB のローカル環境 Go で DynamoDB Local を使った時にいろいろハマったのでメモ example
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

文系出身新卒1年目SEがAWS SAA(SAA-C02)を2ヶ月で一発合格した話

はじめに 先日、AWS Solution Architect Associate に無事合格しました。 文系出身SEで、プログラムもまともに書けないど素人(ましてや基盤知識なんて皆無)ですが、 そんな私でも、一発合格できたので、学習時間や使用した教材、学習方法を共有したいと思います。 合格するために使用した教材 テキスト:AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版 Udemy:これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) Udemy:【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) black belt AWS 公式模擬試験サンプル 学習時間 平日:業務後毎日1~3時間(平均2時間程度/日) 休日:3~6時間(平均4時間程度/日) ※試験直前は6時間やってました 上記を2ヶ月続けました。 AWSを業務で使用されている方や、インフラエンジニアの方などは、 こんなに勉強しなくてもSAAは取得できると思います。 私は、そもそもインフラの知識がありませんので、SAAの試験勉強をしつつインフラ周りの用語や概念を理解したので学習時間が長めです。 学習方法 学習の大まかな流れは以下の通りです。最初の2週間を無駄にしたような。。いや無駄ではないと思いたい。 最初の1~2週間でテキストを通読       ⇩ 模擬試験を解いてテキストだけでは無理だと気づく       ⇩ Udemyの講座が良さそう       ⇩ Udemy+Black Belt が最強と気づく       ⇩ 最後の1ヶ月は、模擬試験の反復 1. テキストを通読 まずは、テキストをざっと読んでSAAで問われるサービスの概要を理解しました。 テキストは、AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版を使用しましたが、オススメ度はあまり高くないです。 模擬試験を解くとわかるのですが、試験で問われるような内容があまり記載されていません。 (最初は、模擬試験の正答率が低く焦りました。) ですのでこちらの教材は、右も左もわからない方向け、サービスの大枠を掴みたい方向けのテキストと言えるでしょう。 2. Udemy講座で手を動かして学ぶ テキストだけでは、合格できそうにないと感じたので、 Udemyで、これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版)を購入しました。(※AWS認定試験取得を推奨されている会社であれば、負担してくれるかも。) この講座で習得できるポイントをざっくりまとめると ハンズオンで使用するAWSセットアップが丁寧に解説されている(特にセキュリティ対策は初学者にとってありがたい内容) AWSが推奨するWell-Architected Framework に沿って各サービス・試験で問われるポイントの解説、ハンズオン形式での環境構築の実施 ドキュメントをダウンロードできるので、学習しやすい 各セクションにふりかえりの小テストあり 最後に3回分の模擬試験あり この講座すごくオススメです。前述したテキスト購入しなくてよかったやんと思えるくらい内容が充実しています。 資料もDLできるので。 受講する際の注意点は、2つです。 動画の作成日を確認しましょう。古すぎるようであれば、black beltで最新の情報をキャッチアップしましょう。black beltは、AWSが公式で公開している資料をまとめたサイトです。PDF、Youtubeどちらでも参照可能です。 ハンズオン内で作成したリソースの削除を忘れないこと。簡単にリソースを作成することができ、最初はとてもテンション上がりますが、削除し忘れたことが原因で、高額な請求が発生することがある(※)ので注意が必要です。各サービスの料金体系をきちんと学習した上で削除可否を判断することが望ましいです。AWSアカウント作成より12ヶ月間は、無料利用枠が設けられているのでその範囲内で作成すれば課金されることはありませんが、特に使用する予定がないのであればすぐに削除することがオススメです。 (※)ハンズオンの中で、インメモリデータベースのElasti Cacheを使用しますが、無料利用枠が設けられているものの、めちゃくちゃ高額なサービスなので削除し忘れて20万相当の請求が発生している方をお見受けしました。気を付けましょう。。 3. ひたすら問題をとく こちらも大変オススメです。ただし、本番試験より難易度高めな問題が多い点だけ注意です。 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) 模擬試験を使用したおすすめの学習方法は以下の通りです 本番環境同様に140分の時間を確保する 悩んだ問題にはチェックをつけて見直しを行う 正解、不正解の問題双方の解説を読み、不明な点は調べる(おすすめはblack belt) 頻繁にミスする問題や、よく出る問題は、サービスごとにメモでまとめる black beltは、SAA試験対策に限らず、業務・AWS認定試験の学習でもよく参照することになりそうです。 最後に、各サービスごとによく出る問題をまとめることはとてもオススメです。 サービスの整理につながりますし、直前の見直し資料としても大変有用です。 私は、Notionを使用してまとめました。 自分だけがみるので間違った問題をそのままコピペしたり、よく問われるサービスのポイントをメモしてました。 こんな感じ↓ (上記は、一部ですがメモしすぎて直前に全部見れませんでしたね、、) まとめ 試験に合格する知識をつけるためには、数をこなすこと、不明点はblack beltで解決するがベストだと感じました。特に後者を実施することで、業務に活かすことができる汎用的な知識を習得できるのでオススメです。 これから受験される方は頑張ってください!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS,Azure,GCPの3大クラウドのアーキテクト試験に合格してみての個人的比較 (2021年版)

以下の記事の2021年版として勝手に書いてみます。 https://qiita.com/yomon8/items/f812079d0ce631f73d45 全て2021年に取得しましたので直近の内容がお伝えできていると思います。 AWS Solution Architect Professional Azure Solutions Architect Expert GCP Professional Cloud Architect 3大クラウドアーキテクト試験で共通していること 身分証明書が2種類必要 筆者の場合は自動車運転免許証 + クレジットカード 実技試験はない 全体的にインフラエンジニアの領域に偏った問題が出題される クラウドファースト (クラウドとしてあるべき姿) が理解できていることが求められる AWS Solution Architect Professional よく言われていることですが試験時間に対して設問数が多く集中力を維持するのが大変です。対策本や対策サイトが多いので対策はしやすいと思います。時間をかけてAWSサービスについて理解をする必要があります。また、AWSは三大クラウドで一番サービスが多いので類似サービスの使い分けであったり、同一サービスの中での方式の違いの特徴であったりをよく把握しておく必要があると感じました。 受験料:300 USD (※筆者は半額バウチャーで受験) 認定期間:3年 再認定:認定期間が切れるまでに再受験 申し込みページ:AWS認定 Azure Solutions Architect Expert 2021年現在では「試験 AZ-303」「試験 AZ-304」の二つに合格することで認定されます。今はちょうど過渡期であり将来的には「試験 AZ-104」「試験 AZ-305」に変更となりアソシエイトの試験の延長という形に変わる予定です。 試験の内容としてAzureサービスのどれが一番要件にあっているかという問題というよりは具体的なパラメータや設定操作の順番を聞いてくる問題の方が多いような印象をもっています。例えば権限ロール。 試験の中でシナリオ問題→通常問題、通常問題→シナリオ問題というように違う問題種別への切り替えが発生しますが切り替えた後は戻ることができないのでシナリオ問題はシナリオ問題で見直し、通常問題は通常問題で見直しということが必要となります。 また、同じ設問で以下のような ○○○のときに使うべきはxxxか? ・Yes ・No のxxxの箇所だけが変わる問題も前の設問に戻れないです。これ以降は戻れませんという旨の注意書きが都度表示されるので見落とさないように気をつけましょう。 試験画面は3大クラウドの中では一番リッチで日本語→英語の切り替えだけではなく色の切り替えもできます。アンケートはありません。 試験対策としてはWeb上に受験報告があるので参考にしやすいです。また、 Microsoft Learnそのものだったり、Web問題集そのものだったりという出題が現状だと目立つ のでそういう意味では一番対策しやすい試験でした。 受験料:21103円 × 2 (※筆者はそれぞれ半額バウチャーで受験) 認定期間:1年 再認定:無料の再認定課題を突破すること 申し込みページ:認定資格および試験を見る GCP Professional Cloud Architect GCP Professional Cloud Architectは 設問数が少なく試験時間が長いので 試験時間が足りないということはないと思われます。AWS,Azureに比べると全体的に独自路線である気がします。 Google Cloudの中で使うという前提ではあるもののJavaやPython、SQL、Kubernetesあたりの知識が問われる問題も少ないですが出たりします。 独自と感じる例としては、 合格すると無料でGoogle Cloudグッズがもらえる 筆者はかばんを選択 受験後に試験のスコアがわからず知ることができるのは合否のみ 合否(暫定)をテストセンターで確認するにはアンケート回答が必要 帰宅後に試験申し込みサイトで合否(暫定)を確認することはできる 受験開始直後に表示される再受験ポリシーのリンクを踏むと元に戻る方法がない 仕方なく試験画面を終了し試験官を呼んで対処してもらった。 参考 シナリオ問題が試験問題画面の右側に表示され続ける 設問を英語で確認することができない 機械翻訳による微妙な翻訳の対策としてベンダー試験では英語で確認したい場合がある ピアソンVUEに委託していない Webassessor に委託 Google Cloud Webassessor の仕様で言語 (日本語,英語) 毎に別アカウントが必要 参考1 参考2 デジタルバッジの管理サイトがcredlyではない テストセンターの受付で「受験者承認コード」の提示が必要 認定試験の購入確認メールやリマインダメールに記載しているのでメールを印刷する 試験対策としてはCourseraやGoogle Cloud Skills Boost (Qwiklabs) が充実しているので無料キャンペーンなどを活用しながら受けると良いと思います。また、クラウドエース社が公式模擬試験の解説記事を出しているのでそれを参考にするのも良いと思います。公式模擬試験自体は無料でいつでも受けられます。 全体的にシナリオ問題が多いです。 Google CloudのVPC (ネットワーク) の考え方はAWS,Azureと大きく違うというのはありますがGoogle Cloudサービスの数はAWS,Azureに比べれば少ないので慣れるとシンプルという印象を受けるかもしれません。 余談ですがCourseraのキャンペーンで割引バウチャーを入手したので適用しようとしたら英語版試験のバウチャーは日本語版試験には適用できなさそうでした。 受験料:$200(税別) 認定期間:2年 再認定:失効までに再度合格する (失効日の60日前から受験可能) 申し込みページ:準備ができたら
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSの知識まとめ(初級)

最近バックエンドエンジニアをしていても、インフラの知識が必須のようなイメージ があるので実務では使ってないが少しずつ知識をためていこうと思う! 基本もろもろ ルートユーザーとIAMユーザーがあり、基本的にはIAMユーザーで作業を行う 操作ログはCloudTrailで追跡できる、S3に保存される
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Code シリーズ要旨

CI/CD アプリケーションの開発フェーズにおける自動化を行い、開発チーム、運用チームに生じる問題を解消するためのソリューションです。 AWSのCodeシリーズは、この CI/CD を果たすための役割としてサービスを提供しています。 Code Commit (継続的インテグレーション) Code Commit はAWS上にプライベートな Git リポジトリをホストし、複数の開発者が共同で効率的に作業を行うために提供されたソース管理サービスです。 任意のIAMユーザーからソースコードをリポジトリにpushし、プルリクエスト、コミットの機能を利用して、リポジトリのソースコードに対して変更管理を行う事が可能となり、AWS上でセキュリティを保全しながら共同開発が行えます。 ブランチと呼ばれる、マスターの変更管理から派生した特定の開発工程を管理するための機能を作成する事が可能で、Masterブランチから分岐したブランチにより、開発者は不特定多数のソースコードに対して並行作業をする事が可能です。 リポジトリのプッシュをトリガーにメールを通知させたり、ビルドの開始を Code Pipeline を使用せずに行えます。 Code Build (継続的インテグレーション) ソースコード(S3,CodeCommit,Gitサービス)をコンパイルし、テストの実行、デプロイ可能なパッケージの生成を行うサービスです。 ビルド環境として生成される Docker Image、ECR リポジトリ、コンピュートリソース(Amazon Linux2、ubuntu) を選択し、buildspec.yml に記載された手順に沿ってビルド環境を生成していきます。 バッチビルドを有効化して、同時ビルドと協調(逐次)ビルドを指定出来ます。 ビルドしたファイルをS3にアップロードしたり、ビルド環境を Cloudwatch Logs へメトリクスおよびログを出力する事が可能です。また、通知ルールを設定して、SNSでビルド状況の通知を受けることも可能です。 VPC内にCodeBuildを配置する事も可能で、テスト環境として DB にアクセスしたい要件を満たすためRDS等へのアクセスする事も可能です。 Code Deploy (継続的デプロイ) アプリケーションのデプロイを自動化するサービスです。 EC2インスタンス、オンプレミスインスタンス、Lambda関数、ECS Fargateのうちデプロイ先を採択し、デプロイグループを作成します。デプロイ先にはデプロイエージェントを導入します。 デプロイ設定により、任意のデプロイ方式を設定する事が可能で、LB を使用した Blue/Green方式、あるいは Inplace方式を採択する事も可能です。 appspec.yml と呼ばれる deploy をするための仕様書を用いて、記述通りのdeploy 方式を行う事が出来ます。 アプリケーションのソースコード、リビジョンは、S3,GitHubに配置し、appspec.yml と共にクライアントからデプロイが開始できます。 デプロイが失敗、あるいは任意のしきい値を超過した場合自動ロールバック機能が動作し、以前のアプリケーションリビジョンの状態に戻すための手動ロールバック機能が提供されています。 Code Pipeline (継続的デリバリー) Source Stage / Build Stage / Deploy Stage をそれぞれ定義し、定義されたサービスのオブジェクトに対してCI/CD のステップを自動化します。 Source Stage では、開発者のインテグレーションにより発生した変更をCloudwatch Events またはWebhookにて検出します。 検出をトリガーに後続の Build Stage で定義されたサービスのアクションが実行されます。先述したようにビルド環境を生成し、テストを実施するサイクルを提供します。(省略可) ビルドが完了すると、Deploy Stage で定義したサービスに対してデプロイを自動で実施します。 Code Artifact 開発に利用される python,java,nodejs等のパッケージマネージャーをAWS にキャッシュしたり、プロキシとして使用する事で、ダウンロードする手間を最小限に抑えたり、アクセスに制御を掛ける事が可能です。 Domain と呼ばれる後述のリポジトリを管理する定義を行い、ドメインの内部に複数のリポジトリを配置します。ドメインに対してJSON形式のポリシーを設けてアクセス制御を行う事が可能です。 リポジトリは使用するパッケージを含みます。アップストリームリポジトリと呼ばれる、パッケージマネージャとの外部接続の関係性、および一般リポジトリとの上下関係を持つリポジトリを定義する事が可能で、開発者は一般リポジトリとのアクセスを行う事で最新のパッケージマネージャをインターネットを介さずに入手出来ます。また、リポジトリにもポリシーが作成可能で、ここでアクセス制御を行う事が出来ます。 Code シリーズによるCI/CD の自動化 順番が前後する場合や、不要なフェーズを省略する事も可能かと思いますが、これら Code サービスを使用して CI/CD の全体の流れがAWS 上で実装出来るという便利なサービスです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CNAMEレコードとALIASレコードの違い

前提 ドメイン名からI Pアドレスを受け取って通信したい AWS S3とRoute53使用 Aリソースレコード(Aレコード)とは、ドメイン名に対するIPv4アドレスを指定するリソースレコード。同じドメイン名に対して複数記述することができる。 CNAMEレコードの場合 DNSの名前解決では、CNAMEリソースレコードが見つかった場合、ドメイン名を正式名に置き換えて名前解決を継続します。 つまりCNAMEレコード名でアクセスしたらAレコード名を返す。 でも通信するためにはIPアドレスが欲しいので、Aレコードが返されたらそのAレコード名を使用して名前解決をしてIPアドレスを受け取る。 赤のアドレスでIPアドレスが欲しいとRoute53にリクエストを送るとCNAMEレコードの青のアドレスをクライアントに返す。 でもまだIPアドレスは手に入れられていないので、 クライアントは返ってきた青のアドレスを元にRoute53に問い合わせをしてAレコード内の黄のアドレスでS3でIPアドレスを取得し、クライアントに返して通信が成功する。 => クライアントとRoute53の通信が2回行われる ALIASレコード Amazon Route 53 エイリアスレコード で、DNS 機能に Route 53 固有の拡張機能が追加されます。エイリアスレコードを使用すると、選択した AWS リソース (CloudFront ディストリビューションや Amazon S3 バケットなど) にトラフィックをルーティングできます。また、エイリアスレコードにより、ホストゾーン内のあるレコードから別のレコードにトラフィックをルーティングできます。 クライアントはRoute53に対してIPアドレスの問い合わせをすると、Route53はAレコードのALIASがあればそれを元にAWS内でS3に問い合わせをし、IPアドレスをクライアントに返す。 (AレコードなのでIPアドレスを返す) => クライアントとRoute53の通信は1回で済むのでCNAMEを使うよりも通信の速度が上がる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

IAMについて

AWSのCloudPractitionerの勉強の過程で、IAMについて紛らわしかったのでまとめる。 私はAWSについてちゃんと勉強する前、個人開発でEC2を使っていたことがあった。 その際管理者アカウントを常に使っていたので、「この機能いる??」と思っていた。(いらない機能わざわざ用意しないよねってのは置いといて、、) IAMとは Identity and Access Managementの略。その名の通り、アクセス権限と認証を管理する機能。 いつ使うのか 各アカウントにリソースを使う権限を付与したいとき。 IAMポリシー 権限が書かれたファイル。 誰がどのサービスのどのリソースに対してどんな操作をするのか、といったことをJSON形式で記述する。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "*" } ] } こんな感じでどんな操作を許可するのかが書かれてる。 IAMユーザー 管理者が作って、誰かに渡すアカウント。 マネジメントコンソールから作れる。 ユーザーにポリシーを割り当てることで、そのユーザーにポリシーの内容を適用できる。 IAMグループ IAMグループにIAMポリシーを割り当てられる。 IAMグループにはIAMユーザーを追加することができて、グループ内のユーザーはグループに付与されたポリシーの内容が適用される。 まとめると、「逐一IAMユーザーにポリシー割り当てるの面倒だからグループにいれちゃおうね」といった感じ。 以上IAMポリシー、IAMユーザー、IAMグループのぼんやりとした内容でした。 かなり大雑把なので不安な人は一次情報当たってください。 AWS公式docs
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む