きっかけ 最近、プリセールスを手伝うことが多く、そのため、アプリアーキテクチャ、インフラ構成図をよく書いています。 まずExcelで作成して、レビューOKになったものを提案書用にPPTに修正して、、、という二度手間が発生していたので、同じ形式できれいに作れないかと検索した結果、Draw.ioに行きつきました。 前提 VSCodeインストール済み 構築手順 Draw.io Integrationプラグインの導入 構成図作成 ファイル出力 1.Draw.io Integrationプラグインの導入 以下リンクでInstallを押下するか、VSCodeのプラグイン検索で"Draw.io"で検索するかでDraw.io Integrationのインストールを実施する。 (インストール後、VSCodeの再起動を推奨) 2.構成図の作成 .drawioなどDraw.ioに関係する拡張子を持つファイルを作成、読み込むと方眼紙のような編集画面が開きます。 左側メニューで検索すると関係するアイコンが表示されるため、選択して配置することができます。 左メニュー下の"More Shapes"でAWSアイコンセットなどを選択することができ、左mニュー欄に追加することもできます。 最近、よく書いているインフラ構成図の一部を作成すると以下のようになりました。(Draw.io使用している間は明るめのテーマがよさそう…) 3.ファイル出力 ファイル出力するには、File>Exportから可能。出力形式はsvg, png, drawioが選択できる。 pngで出力してみたが画質が悪かったため、File>PropertiesからZoomの値を上げるて再出力すると画質が向上した。 最終的に出力したpngは以下。

きっかけ とある案件の要件確認MTGをしているときに、 僕:「LambdaAを動かすために定期的にLambdaBを動かす構成」 ?:「LambdaBを定期実行ではなく、条件を満たしていない時だけ動かしたい」 みたいな話があり、そういやLambdaから他のLambdaを動かす方法ってどうやるのか？という疑問から ※ そもそもLambdaから他のLambdaを呼び出すことに抵抗があり、できれば定期実行を軸に進めたいのは本音。フェイルセーフ的な位置づけでロジック自体は実装することになりそうとの考察。(基本は定期実行。なんらかの問題で条件を満たさない場合があればLambda呼び出し実行。) Best Practiceに沿った内容があればコメントください。。。 前提 AWS: 社用アカウント利用 Summary 呼び出す側Lambda関数で、AWS-SDKのインポート、AWS-SDK.Lambdaのインスタンス化、Lambdaインスタンスでinvoke関数の実行 呼び出す側Lambda関数のIAMポリシーに "lambda:InvokeFunction"を許可する設定を追加 構築Step 呼ばれる側Lambdaの構築、ソース修正 呼ぶ側Lambdaの構築、ソース修正 呼ぶ側Lambdaに紐づくIAMロールの修正 動作確認 1. 呼ばれる側Lambdaの構築、ソース修正 AWS Lambdaのダッシュボードから'関数の作成'を押下 以下、添付画像の内容へ変更、'関数の作成'を押下 関数名: test-called-function ランタイム: Node.js 14.x デフォルトの実行ロールの変更: ☑基本的な Lambda アクセス権限で新しいロールを作成 作成完了後、コードタブでソースコードを以下に修正、デプロイ index.js exports.handler = async (event) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Called Lambda!'), }; return response; }; 2. 呼ぶ側Lambdaの構築、ソース修正 AWS Lambdaのダッシュボードから'関数の作成'を押下 以下、添付画像の内容へ変更、'関数の作成'を押下 関数名: test-calling-function ランタイム: Node.js 14.x デフォルトの実行ロールの変更: ☑基本的な Lambda アクセス権限で新しいロールを作成 作成完了後、コードタブでソースコードを以下に修正、デプロイ index.js 'use strict'; const aws = require('aws-sdk'); const lambda = new aws.Lambda(); exports.handler = async (event) => { const params = { FunctionName: 'test-called-function', InvocationType: 'RequestResponse', }; const result = await lambda.invoke(params).promise(); const response = { statusCode: 200, body: JSON.stringify(result), }; return response; }; 3. 呼ぶ側Lambdaに紐づくIAMロールの修正 test-calling-function関数の画面で設定タブ>アクセス権限>実行ロールで記載されているロール名リンクを押下 IAMロール画面でリンクになっているポリシー名を押下(例: AWSLambdaBasicExecutionRole-XXXXXX) IAMポリシー画面で'ポリシーの変更'を押下 JSONタブに切り替えて、以下のアクセス情報を追加 IAMポリシー { "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": test-called-functionのARN (例:"arn:aws:lambda:ap-northeast-1:XXXXX:function:test-called-function") } 4. 動作確認 test-calling-function関数の画面でテストタブを選択、テンプレート名を適当に入力し、'テスト'を押下 - 実行結果: 成功、　詳細の返却値が以下のようになっていることを確認 レスポンス { "statusCode": 200, "body": "{\"StatusCode\":200,\"ExecutedVersion\":\"$LATEST\",\"Payload\":\"{\\\"statusCode\\\":200,\\\"body\\\":\\\"\\\\\\\"Hello from Called Lambda!\\\\\\\"\\\"}\"}" } 参考サイト

　はじめに 　こんばんは！今回はDVA対策で勉強しているときに出てきたDynamoDBのAPIとプレースホルダー、についてまとめてみました。 　試験で出てくるかは別として、業務で使うことも今後あると仮定して記事にしてきたいと思います！！！ 　よろしくお願いします(｡･ω･)ﾉﾞ 　DynamoDBのCRUD処理 　Amazon DynamoDBでは、項目は属性の集まりです。各属性には名前と値がありまる。属性値はスカラー値、セット型、ドキュメント型のいずれかになります。 　DynamoDB は、作成、読み込み、更新、削除 (CRUD) の 4 つの基本的なオペレーション機能を提供します。 ◆DynamoDBのCRUD 　　・PutItem ：作成 　　・GetItem ：読み込み 　　・updateItem ：更新 　　・DeleteItem ：削除 この４つ以外にも下記のオペレーションがあります 　Batch 　大量のデータの書き込みや読み込みをまとめて行うときにPutItemやGetItemによるオペレーションでは非効率な場合があります。その場合に使用するオペレーションを紹介します。 　◆Batch 　　・BatchGetItem：大量データの読み込み操作 　　・BatchWriteItem：大量なデータの書き込み操作 　BatchGetItemとBatchWriteItemによって並列処理ができて、パフォーマンスの向上が期待できます。一部の項目の書き込み、読み込みが失敗しても処理が継続し失敗した項目は、レスポンスのUnprocessedItemsに含まれるので、失敗原因や失敗処理、場合によっては再試行処理が行われる。 　Transaction 　複数のテーブルでタイミングを合わせて処理を行いたい場合はTransactWriteItemes、TransactGetItemsを使用する。トランザクションを成立させる必要上、１つでもリクエストが失敗した場合は処理全体を失敗にする。 　 　◆Transaction 　　・TransactWriteItemes：複数テーブルへのタイミングを合わせた書き込み処理操作 　　・TransactGetItems：複数テーブルへのタイミングを合わせた読み込み処理操作 　この2つの操作は2018年に追加されたオペレーションであり2018年以前はDynamoDBではトランザクションはサポートされていなかった。現在はサポートされているので、認定試験対策として「DynamoDBはトランザクションをサポートしているNoSQLDB」である。 　PutItemについて 　新規項目の追加はPutItemオペレーションで行い同じキーを持つ既存の項目があった場合は、既存のアイテムがPutItemされたアイテムに置き換える 　UpdateItemについて 　DynamoDBテーブルの特定のアイテムの特定の属性のみを更新するときに使用されるUpdateItemオペレーションですが、予約語を属性として使用する場合はプレースホルダーを使用しなければならない。 　◆プレースホルダー 　　・ExpressionAttributeNames：予約語を属性として指定する 　　・ExpressionAttributeValues：予約語を更新する値 　DynamoDBテーブルにUpdateItemを実行する際に、オプティミスティックロックを使用する場合はConditionExpressionを使用すると条件付きのUpdateItemができる。 　・オプティミスティックロック 　　　更新 (または削除) しているクライアント側の項目と、Amazon DynamoDB の項目を確実に同じになるようにするための手段です。 　・ConditionExpression 　　　DynamoDBテーブルにUpdateItemを実行する際にオプティミスティックロックを使用したいときに条件式を指定して使用する場合に使う。 　GetItemについて 　GetItemではプライマリキーが必須であり、特定の属性や強力な整合性で読み込みたい場合はこれらのパラメーターを使用します。 　・ProjectionExpression：取得したい属性の指定 　・ConsisitentRead：強力な整合性を指定 　DeleteItemについて 　キーを指定して項目を削除することができる。 　・ReturnValues：削除前の項目の取得をすることができる。 　おわりに 　今回もお疲れ様でした。仕事終わりに少しづつ書いてきたので全然進みは遅かったですが、また来週も書いていこうとおもいます。 　お疲れ様でした(｡･ω･)ﾉﾞ

まず始めに この記事はAWSのALBでのCookieによる振り分け設定をまとめたものです。 　 ALB(Application Load Balancer)の振り分け 基本的な説明は省略します。(こちらを参照ください。) まずAWSでのLB作成の際には主に以下の種類があります。 ・ALB(Application Load Balancer) 　...HTTP,HTTPSのトラフィックをリクエストレベルで動作し、高度なルーティング設定が可能です。 ・NLB(Network Load Balancer) 　...大規模なTLSオフロードやアプリケーションの性的IPが必要な場合に、 　　　接続レベルで動作し、低いレイテンシーで大量のリクエストを処理できます。 ・GLB(Gateway Load Balancer) 　...ファイアウォール、侵入検知・防止システムなどの仮想アプライアンスをデプロイスケーリング管理できます。 ・その他(Classic Load Balancerなど) 　...EC2-Classic ネットワークで既存のアプリケーションを実行している場合に使用します。 今回はHTTPSでのリクエストを振り分けのためALBを使い、条件にCookieを用いる方法をご紹介します。 HTTPSリクエスト振り分け 　基本的にAWSでALBを作成する際にリスナー(設定したプロトコルとポートでの接続リクエストをチェックするプロセス)も一緒に作成します。プロトコルはHTTPもしくはHTTPSを選択できますが、HTTPSの場合、証明書も必要です。 　リスナーのデフォルトアクション(追加した条件に当てはまらない場合)を設定するため、ターゲットグループ(1つ以上のルーティング先を含めたもの)も作成します。 　 Cookieによる振り分け 　ターゲットグループ1にアプリケーションa,アプリケーションbを設定し、負荷分散を行っているとします。 アプリケーションaでリクエストを処理したあと、再度同じアプリケーションaにリクエストを送りたい際に、このままではアプリケーションbに送信される可能性があります。 そのため、リスナールール(リクエストごとにチェックする条件)にアプリケーションで付与したCookieをしようして、振り分けたいと思います。 まず、ターゲットグループ2(アプリケーションaのみリクエスト送信)とターゲットグループ3(アプリケーションbのみリクエスト送信)を作成します。 アプリケーションで付与するCookieがそれぞれapl=a,apl=bとします。 リスナールールにHTTPヘッダでCookieがapl=aのときにターゲットグループ2にルーティング、 HTTPヘッダでCookieがapl=bのときにターゲットグループ3にルーティングする2つのルールを作成します。 以上で振り分け設定は完了です。 検証方法としては下記のcurlコマンドでCookieを自由につけて検証が可能です。 curl -H 'Cookie:apl=a' [URL] 追記 　上記で作成したリスナールールだとCookieが複数あった場合にうまく振り分けされない。 　(原因としては複数のCookieを一つのヘッダとして送るため。) 　そのため、ヘッダの条件部分を*apl=a*とすることで振り分け可能。 最後に 　今回はALBでのCookieによる振り分け設定を簡単にまとめてみました。 　同じターゲットグループにリクエストをしたい場合に 　Cookieを用いずとも、ALBのスティッキーセッション機能をしようして行う方法もあります。 セッション維持の期間なども細かく設定できるため、またいずれまとめようと思います。 最後まで読んでいただきありがとうございました。 　

AWSのECSで、「コンテナ内の特定ディレクトリをローカルに落としたい！」という機会があったので書いときます。 sshをして、 ssh先にコピーをして、 ローカルに落とす。 そんな手順でやればできますね。 sshログイン $ ssh -i <キーのある場所>/<キーの名前> <インスタンスのユーザー名(ec2-userとか)>@<ssh先のパブリックIP or DNS> セキュリティグループでsshの設定をし忘れてると、Connection timed outになりますね。 dockerからssh先にコピー ssh先で $ docker ps $ pwd $ docker cp <dockerコンテナ名>:<docker内のコピーしたいディレクトリのパス> <ssh先のコピーファイルを仮置きするパス> docker cpコマンドはファイルでもディレクトリでもオプションなしで問題ないです。 ssh先からローカルに落としてくるコマンド ローカル環境で $ scp -i <キーのある場所>/<キーの名前> -r <ssh先のパブリックIP or DNS>:<ssh先のコピーファイルを仮置きするパス> <ローカルのファイルを置きたいパス> しょうもないのですが、sshしている中からscpコマンドを叩いて少しハマってました。 ssh: connect to host port 22: Connection timed outが出ていたので、「あれ？sshってそこまで遅いんだっけ？」とか思ってました...

はじめ PrimeHub CEは環境によって様々なインストール方法がありますので、今回はAWS EC2のインスタンスにシングルノードMicroK8Sでインストールをします。 AWS EC2インスタンスの準備 インスタンス：t3a.xlarge (4vCPU/16 GiB) (これ以上を推奨します) AMI：Ubuntu Server 18.04 LTS (Ubuntu 20.04 LTSのサポートはしません) Security Groupの設定 Storage：20GB (これ以上を推奨します) インスタンスにPrimeHub CEをインストール 本文記載時点はPrimeHub CE v3.6を参考にしています。 インスタンスにSSHでログインする ssh -i xxxx ubuntu@ec2-ww-xx-yy-zz.ap-northeast-1.compute.amazonaws.com 最初にパッケージ管理リストを更新する sudo apt-get update PrimeHubリポジトリをクローンする git clone https://github.com/InfuseAI/primehub インスタンスにMicroK8sでシングルノードを築く cd primehub/install ./primehub-install create singlenode このメッセージが出たら、一回SSHからexitをする [Require Action] Please relogin this session and run create singlenode again exitをしたら、再度SSHでログインする exit ssh -i xxxx ubuntu@ec2-ww-xx-yy-zz.ap-northeast-1.compute.amazonaws.com もう一度同じコマンドをする cd primehub/install ./primehub-install create singlenode 少し待つとシングルノードが完成する nginx-ingressの動きを確認する curl ec2-ww-xx-yy-zz.ap-northeast-1.compute.amazonaws.com default backend - 404が表示されたら正常。 MicroK8sクラスタの情報を確認する kubectl cluster-info PrimeHub CEをインストール ./primehub-install create primehub --primehub-version v3.6.0 --primehub-ce --helm-timeout 2000 インストールの途中で三箇所の入力の必要あり PRIMEHUB_DOMAIN： インスタンスのPublic IPv4 DNSを設定する。 e.g.ec2-ww-xx-yy-zz.ap-northeast-1.compute.amazonaws.com KC_PASSWORD：Keycloak web consoleのパスワードを設定する。 PH_PASSWORD：PrimeHub web consoleのパスワードを設定する。 ユーザー名はphadminに固定されており、KeycloakとPrimeHubも同じユーザー名です。 インストールをしながら、別のterminalでSSHでログインして、インストールの状態を観察する。 watch "kubectl -n hub get pod" 最初 インストールの途中 インストール完了のステータス インスタンスによって完了までにかかる時間は異なる primehub-bootstrap-xxxはCompletedのステータスになり、全て他のポッドはRunningのステータスになる。 PrimeHubウェブサイトにログインする ウェブサイト：ec2-ww-xx-yy-zz.ap-northeast-1.compute.amazonaws.com ユーザー名：phadmin パスワード：設定したパスワード Notebookを起動する ? PrimeHub CEを試してみましょう? PrimeHub について PrimeHubリポジトリ PrimeHub CE 紹介〜チーム向け機械学習プロジェクトとリソース管理が楽になる PrimeHub ドキュメント

はじめに オリジナルアプリの完成が近づいてきました。もっともっと盛り込みたい機能が山ほどあるのですが、転職活動のほうも疎かにできないので、とりあえずAWSにはデプロイしようということで作業を進めていました。 AWSにデプロイするにあたって、アプリの改修などをした際に、結構たくさんのコマンドを打たなければならなくて、大変なので自動デプロイを導入しました。 Capistranoという自動デプロイツールを使って導入したのですが、完成後、手動デプロイしていた時にはしっかり表示されていたアプリ内で使われている画像たちが表示されなくなってしまいました。 明確な理由はわからないまま、自分なりに仮説を立てて解決できましたので記事に残しておきます。 よろしくお願いします。 画像が表示されなくなった 私の画像はapp/assets/imagesの配下に置いていて、img_tagで呼び出していました。 手動でデプロイを行なっていた時は、ちゃんと呼び出されていたのですが、自動デプロイをした後に小さな画像が壊れたようなマークだけが表示されて、目的の画像が表示されていなくなりました。 確実に自動デプロイの過程で問題が生じたとしか考えられませんでしたので、その辺を振り返っていたところ、そういえばアプリのファイルたちの階層を一段階深くしたために、パスを書き換えた作業を思い出し、これが怪しいんじゃないかと思いました。 解決 もしかするとパスが変わっているのかもと思い、その周辺をネットで嗅ぎ回っていたところ、やはり自動デプロイの際に画像がコンパイルされ、パスが変わるのだとおっしゃっている方がいました。あまり意味はわかっていませんが。。。 その方が言うには↓（下記のコードは私のコードをもとに作成しています） <%= image_tag "Textbook student.png" %> このようなコードを <%= image_tag asset_path("Textbook student.png"%> というふうに書き換えることで解決できるそうなので試してみました。 しかし、私の場合うまくいきませんでした。。。 パスが悪いのかどうかわからないですが、他にパスを書き換えるとしたら、、、と考えていたら一つ思い浮かびました。 もしpublicフォルダの配下に置いたらどうなるのかな、と思いまして、画像たちをpublicフォルダ配下へお引越しさせ、パスを下記のように書き換えました。 <%= image_tag "/Textbook student.png" %> public配下の時は相対パスで/を置いてあげるだけで場所を示せるのですね。 初めて知りました。 これでどうだと言わんばかりにデプロイしてリロード押したら、見事に画像の表示に成功しました！ 本当の解決 実はこの記事を書いた後に、理由が判明しました。 自動デプロイをした際にいじっていたNginxの設定に記述ミスがありました。 こちらその設定画面↓ upstream app_server { # Unicornと連携させるための設定 server unix:/var/www/リポジトリ名/shared/tmp/sockets/unicorn.sock; } # {}で囲った部分をブロックと呼ぶ。サーバの設定ができる server { # このプログラムが接続を受け付けるポート番号 listen 80; # 接続を受け付けるリクエストURL ここに書いていないURLではアクセスできない server_name Elastic IP; # クライアントからアップロードされてくるファイルの容量の上限を2ギガに設定。デフォルトは1メガなので大きめにしておく client_max_body_size 2g; # 接続が来た際のrootディレクトリ root /var/www/リポジトリ名/current/public; # assetsファイル(CSSやJavaScriptのファイルなど)にアクセスが来た際に適用される設定 location ^~ /assets/ { gzip_static on; expires max; add_header Cache-Control public; root /var/www/リポジトリ名/current/public; } try_files $uri/index.html $uri @unicorn; location @unicorn { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://app_server; } error_page 500 502 503 504 /500.html; } コメントアウトで「assetsファイル(CSSやJavaScriptのファイルなど)にアクセスが来た際に適用される設定」と書かれている中の、リポジトリ名に置き換えるところを、置き換え忘れていました。 通りでpublicだったら反映されたわけですね。。。 今後気をつけたいと思います。 最後に assetsの配下に置いていた画像も実は一部ちゃんと表示はできていたので、パスはあまり関係なかったと思います。画像の容量が大きかったのかなと言う気もします。わかる方がいればコメントお願いします。 ネットを徘徊していた時に思ったことは、本来publicの使い方とassets/imagesの使い方はそれぞれ特徴があり、どこに画像をおくべきかはいろんな意見があるように感じました。 またちゃんと理解した時に記事書けたらなと思います。

概要 S3上にあるParquetファイルをRedshift内部テーブルへインポートするためCOPYコマンドを実行。データ量が多く、COPYコマンド完了までに数時間かかった。その間、別のバッチが動き、COPYコマンド実行中のS3パスに対してのデータ出力とCOPYコマンド実行が走ってしまった。その際の挙動について記載します。 (2021/07/15時点の内容です。) ケース S3上にあるParquetファイルをRedshift内部テーブルへインポートするためCOPYコマンドを実行。（データ量が多く、完了に数時間かかる） 上記実行中に別のデータ処理バッチが動き以下のヤバそうな処理が実行される。（上記実行開始してから数分後です） (1)上記COPYコマンドのFROM句に指定しているS3パス配下にParquetファイルを出力（Unloadコマンドによる） (2)さらに(1)で出力されたファイルをRedshift内部テーブルへインポートするCOPYコマンドを実行（対象テーブルは上記COPYコマンドと同一） 挙動 まず(2)については、処理が開始されない（エラー終了するわけでもない）。最初に実行しているCOPYコマンドによって該当テーブルへの書き込み処理がロックされてる感じ？ （コマンド実行は中断させたので放置していたらどうなっていたかはわかりません） (1)については、出力は問題なくされました。気になるところは最初のCOPYで、この後から出力されたファイルがCOPYの対象になるかどうかですが、対象になりませんでした。タイミングによっては変な動きとかするかもしれませんが、基本的にCOPYコマンドを実行した時点でCOPY対象をファイル単位で確定させているという感じですかね。 感想 上記のケースは特殊ケースかつRedshiftの操作としてよろしくないものであり、本来防ぐべき事象だったかと思いますが、Redshift側の挙動は非常に助かる最善と言っていい動きだったと思います。

目的 S3の特定オブジェクトをAWSCLIでEC2のローカルにダウンロードしたい。 発生事象 以下ローカルへのダウンロードコマンドを実行するとAccessDeniedエラー $ aws s3 cp s3://sourcebucket/object.jpg ./ download failed: s3://sourcebucket/object.jpg to ./object.jpg An error occurred (AccessDenied) when calling the GetObject operation: Access Denied バケットポリシーとIAMロールの権限周りを確認するが、実行可能な権限設定に見える。 事実、GetObjectと同様に設定したListBucket権限の以下コマンドを実行すると正常に機能 する。 $ aws s3 ls s3://sourcebucket/ 2021-07-13 10:56:40 8574 object.jpg 原因と対処 S3バケットのデフォルト暗号化の有効（KMS）に起因していた。 そのため、S3バケットで使用しているKMSの「キーユーザー」にユーザーまたはロールを追加して解決した。 参考 以下のおかげで解決に至りました。 https://base64.work/so/amazon-web-services/1209321

webエンジニアならAWSは必須ですね。 最近は、サーバーレスも定着してきて、これまでのEC2メインでもなくなってきたので、勝手ランキングを発表！ （2021年上半期版） これからのwebサービス開発の参考にしてください。 人気awsリソースランキング　4位～10位 第 4 位 Lambda 軽いちょっとした処理は、lambdaにして呼び出すのが便利ですね。 もう自前ライブラリを構築する必要はなくなりました。 AWS Lambda 料金 第 5 位 DyanmoDB NoSQL便利！しかも、速い！スケーラビリティ！ RDB思想からの脱却に苦労するかもしれませんが、価値はかなり高いです。 Amazon DynamoDB 料金 第 6 位 API Gateway サーバーを立てて、APIキー認証をしっかり作って、バージョンを管理して、から脱却できます。 トラフィックスピードも制御できるので、もう自前API構築は、きっとしないです。 Amazon API Gateway の料金 第 7 位 Step Functions サーバーレスでは絶対に欠かせません。ロジックを構築できます。 Lambdaでロジックを組む必要がなくなった上、図表示できるのでとても理解しやすくなりました。 AWS Step Functions の料金 第 8 位 EC2 やっぱり必要ですね。Linux。 一通りをLinuxで組む場面ではまだまだ現役です。でも最近は、単用途ばかりな気がします。 Amazon EC2 の料金 第 9 位 CodeBuild これがないと何も進みません。devもprodもデプロイするのに大活躍です。 かなり自由度が高いので、複雑でカオスになりそうでヤバイです。 AWS CodeBuild の料金 第 10 位 RDS リレーショナルDBは、当然必要です。歴史もありますし構築しやすいです。 どんなに複雑に組んでも、学習コストが少なくてすむのは素晴らしいです。 Amazon RDS の料金 では、第3位から第1位までの発表です！ 人気awsリソースランキング　3位　CloudShell ご存じですよね！めちゃ便利！ linuxコマンド（aws/cli）を叩くのにEC2を起動する必要はありません！ AWS CloudShell pricing 人気awsリソースランキング　2位　S3 もはや不動のポジション。awsの超初期からあるリソースです。 今だに機能拡張されていて、ファイルを簡単に安全安心に操作できるのはこの上ないメリットです。 Amazon S3 の料金 人気awsリソースランキング　1位　CloudFormation まさかポチポチしてawsリソースをつくっていませんか？作成も更新もコードで管理できます。 インフラをバージョン管理できるのは、セキュリティ観点からもアクシデント観点からもメリットばかりです。 AWS CloudFormation の料金 ハードウェアを管理しなくてよいのは、とてもありがたいです。 これまでは、かなり余裕を見込んだハードウェアを選定してデータセンターに設置、もしくは、同じくスペックを選定してレンタルサーバーを契約。 でオーバースペックや不足が出てしまったら、切り替えるためだけのシステム障害リスクや、精神的負担、段取り、過渡期の無駄費用の発生など大きなデメリットがありました。 でも、ポチポチとクリックしてリソース作成するのは、ドキュメント整備の苦労や属人性などから、実質の再現性が低くなる場面があるため、コード管理できるCloudFormationは重宝します。 以上、2021年上半期ランキングでした。 筆者の見識による勝手な推測ですので、ぜひコメントください。 次に、関心があるのは・・・ 買う側サービスは、とても便利に進化しましたが、売る側は、まだまだなのが現実です なので、今、売る側に注力しています。（と、言ってもかなり前からですが・・・） 一緒に「売り方コミュニケーション」を進化させませんか？ エンジニア募集中です。採用エリアは【日本全国】 【完全リモートワーク】でみんな働いています 学生アルバイト、一般アルバイト、副業、中途社員、新卒社員、業務委託があります エントリーは、https://www.combz.jp/recruit へ

webエンジニアならAWSは必須ですね。 最近は、サーバーレスも定着してきて、これまでのEC2メインでもなくなってきたので、勝手ランキングを発表！ これからのwebサービス開発の参考にしてください。 人気awsリソースランキング　3位～10位 第３位　xxxx ※重要：筆者の勝手な推測ですので、違うぞ！という場合はコメントください。

エンタメ系企業の社内もろもろを担当しているakibinです。 最近はレノン・ステラって人のSummer Feelingsにハマってます。夏だよね〜 やったこと CloudTrailとは？の備忘録です。 CloudTrailとは CloudTrailはAWSの管理コンソールやCLI、SDKなどでどのような操作が行われたか記録するサービスです。 いつ、誰が、何をしたかを記録、確認ができます。 ログの種類 取得されるログは大別すると以下3つです。 管理イベント EC2インスタンスの作成・操作や、S3バケットの作成、IAMの操作などAWSリソース操作全般 デフォルトで有効で、90日間まで無料で記録される。 データイベント S3バケットのデータ操作、Lambda関数の実行などデータ関連のイベント。 データイベント記録は有料。イベントが発生した分だけ料金が発生。 インサイトイベント 管理イベントを分析、異常なアクティビティを検出。 分析は有料。分析した分だけ料金が発生。 CloudTrailのメニュー ダッシュボード イベント履歴、証跡、インサイトがまとめてダッシュボードで確認できます。 イベント履歴 過去90日間の管理イベントを確認可能。 イベントソースで検索するとわかりやすいかもと思いました。 Insights（インサイト） 私はまだ使用したことがないのですが、後述する証跡でインサイトイベントを有効にすると、分析の結果、異常なアクティビティがこのメニューで確認できるようです。 証跡 以下用途で証跡は使用します。証跡を作成すると、ログはS3に保管されます。 管理イベントを90日以上保管する場合（S3の保管費用が発生） データイベントを有効にする（S3の保管費用 + イベントが発生した分だけ料金が発生） インサイトイベントを有効にする（S3の保管費用 + 分析した分だけ料金が発生） 有効にするイベントは証跡作成中に選択できます。 よし、これでとりあえずはCloudTrailが何なのかは理解できました。 これを踏まえて、次回はCloudTrailとCloudWatch Logsを使用して、IAM関連の管理イベントが発生した場合の通知設定方法をやってみようと思います。 ↓↓↓やってみました。 CloudTrailとCloudWatchLogsを使用してIAM関連イベントの通知 こちらもチェックお願いします！ Twitterアカウント Youtubeチャンネル

はじめに 案外見るんですよね, こういった構成. しかし, StepFunctionsは直接リソース操作できる対象が多くあります. ここではDynamoDBだけ紹介しますが, ほかも使い方は似たようなものなのでWorkflow Studioを開いて確認してください. DynamoDBに対してできる操作 GetItem PutItem UpdateItem DeleteItem いずれも1項目を操作する系です. もし複数項目の更新等が必要な場合, Mapを使うと良いです. できない操作 query scan トランザクション 特にqueryはできるようになってほしいところですが, 機能追加を待ちましょう. 使ってみる Workflow Studioで操作すると楽です. わかりやすい! 1つ1つを説明しなくても触ればわかります. Workflow Studioはこの記事を書く1ヶ月前くらいに実装されたもので, このおかげでどのようなものがStepFunctionsから直接操作できるかわかりやすくなっています. ただ, これで全ての機能と設定が組めるというわけではないので, 設定内容によっては普通にJSONを直接触る必要があります. DynamoDBでPutItemするときのJSONはこう "PutItemxxxxx": { "Comment": "DynamoDBにxxxxxを保存", "Type": "Task", "Resource": "arn:aws:states:::dynamodb:putItem", "Parameters": { "TableName": "SampleTable", "Item": { "Attribute1": { "S.$": "$.GetValue.Payload.xxxxx" }, "CreatedAt": { "S.$": "$.GetDate.Payload.Date" } } }, "InputPath": "$", "ResultSelector": {} "OutputPath": "$", "Next": "Parallelxxxxxx" } PutItemだと出力結果は大したものがなく, 通信の情報くらいしかないのでResultSelectorで全部落としてしまって良いと思います. 失敗したならエラーがCloudWatchに出力されるので, ますます不要です. 利点 パッと見わかりやすい Workflow Studioから, パッと見で何のリソースを操作しているのかがわかります. Lambda経由でDynamoDBを操作した場合 StepFunctionsからDynamoDBを操作した場合 ロジックを分解すると再試行処理やエラー処理を組みやすい DynamoDBのCRUDは, キャパシティを超えたりなどでエラーになる場合があります. エラー時は再試行処理を書いたりするわけですが, ロジックをStepFunctions側で作ることでリソースの操作をStateMachine側に外出しでき, エラー処理が容易になります. "PutItemxxxxx": { "Comment": "DynamoDBにxxxxxを保存", "Type": "Task", "Resource": "arn:aws:states:::dynamodb:putItem", "Parameters": { "TableName": "SampleTable", "Item": { "Attribute1": { "S.$": "$.GetValue.Payload.xxxxx" }, "CreatedAt": { "S.$": "$.GetDate.Payload.Date" } } }, "Retry": [ { "ErrorEquals": [ "States.ALL" ], "BackoffRate": 2, "IntervalSeconds": 1, "MaxAttempts": 14, "Comment": "失敗時の再試行" } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "FailState" } ], "InputPath": "$", "ResultSelector": {} "OutputPath": "$", "Next": "Parallelxxxxxx" } 何のエラーで, 何秒ごとに, 再試行のたびにどれだけ間隔を引き伸ばしながら最大何回再試行するか, 設定を書くだけです. 今まではwhileしたりforしたりbreakしたりしていましたが, その必要はなくなりました. 今回の構成の例では, やろうと思えば1つのLambdaだけで処理できます. しかし, エラー落ちは網羅できていて必要ならロールバックをかけられているのか, 失敗時に再試行をすべきところは網羅できているか, いつどのリソースを操作しているのかなど, すぐに判断するのは困難です. ちなみにJSONはWorkflow Studioが勝手に作ってくれます. CFnからリソースを${SampleTable}みたいに指定してとかであれば少し修正が必要ですが, 一から書くよりは遥かに楽なのでコピペしていくと早いです. おわりに ほぼ全て, 新しいWorkflow Studioのおかげです. ローコード開発は, 従来の開発と感覚が全く違うので慣れるまで大変ですが, 慣れたら快適です!!!

勉強前イメージ RDSに接続する際のプロキシ？ 調査 RDS Proxyとは？ 接続元と接続先のRDSの間に設置し、アクセスを中継するサービスになります。 フルマネージド型のデータベースプロキシになります。 設定はRDSのProxiesから設定が出来ます。 ユースケースとしてはlambdaでサーバレスなシステムを構築する際に lambda + RDSだと同時接続数を超えてしまいアクセスできない状態になります。 このときに lambda + RDS proxy + RDS構成でコネクションのプーリングなどを行います。 RDS Proxyを特徴 接続プーリング RDSの接続プールを管理し、アプリケーションからのアクセスと頻度を効率化します。 また、RDSに接続する際のリソースも上記によって軽減します。 シームレス フェイルオーバー RDS proxyは複数のAZにデプロイでき、 フェイルオーバーの際は新しいデータベースインスタンスに直接ルーティングすることで、 アプリケーションの再接続は不要で、ダウンタイムを短縮することが出来ます。 アプリケーション セキュリティの向上 データベースがユーザ名/パスワードしか対応していない場合でも RDS proxyの接続はiam認証が可能です。 また、Secrets Managerによる認証情報の一元管理も行います。 勉強後イメージ max_connectionとかでエラーになってたらこれが良いって感じなんかな？ ただ、読み取りだけの話だったらリードレプリカでも・・？って思ったけど RDS proxyは他にもフェイルオーバーとかセキュリティ面でのメリットもあるし そもそもRDS proxyとリードレプリカはやり方が違うね。 参考 Amazon RDS プロキシ Amazon RDS Proxy のご紹介 RDS Proxyを使った実験

受験のきっかけ とあるSIerで６年間基幹システムのSEをしていたのですが、まあほとんどオンプレ経験しかなく過ごしてきました。 長年勤めた企業を退職し、プログラミング以外の上流・下流工程の経験が多かったので、 「自分も開発できるようになりたいな～」ということで巷で有名なAWS使ってみるか！と触ってみて、あまりの便利さに驚愕したのがAWSとの出会い。 えっ、サーバーすぐ設定して立ち上がるやん！（EC2） えっ、データベースインストールとかの作業いらんの？（RDS） えっ、ロードバランサーとかインフラガチ勢しか出来ないと思ってた（ELB） 丁度スタートアップの起ち上げのお手伝いでAWSのクレジットがあったこともあり、体系的に学んでみようかと思い、今回受けてみました。 結果は合格！ 毎日１時間を３ヶ月、土日はプラス１～２時間というかんじで約１２０時間くらいでしょうか。 勉強法 色んな方が記事にしていたり、知人に聞いても評判だった勉強法がこちら。 Udemyの「これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）」 ほんとうにこれだけで受かりました。ハンズオンが付いていて手を動かしながら学べるので実践的で内容も良いです。 各パートで小テストや模擬試験も３回分ついているので、間違ったところを見直して、分かるまで理解し、 関連することは調べるというような勉強のやり方で間違いなく合格できると思います。 受験当日 受験当日はピアソンVUEで自宅から受験しました。 30分前になったらアカウントログインして机周りの撮影や本人確認などがPCや携帯カメラを使って行います。 受験ポリシーが思ったより徹底しているので、試験官から指摘されて慌てないよう、事前に目を通しておきましょう。 私の場合は、以下のようなことがあったので、もし自宅で受験される方は気を付けてみてください 試験中におしっこにいきたくなる ノートパソコンの電源を付けるの忘れ、電源刺すための身動きがとれないため、電池切れないか焦る 机の上のパソコン以外のモニターやスタンドに服をかけて隠すことを指示され、ちょうど良い服がなくて焦る 頻出問題 模擬試験でもそうでしたが、傾向としてはVPC、EC2、ELB、S3に関する問題が多い気がしました。 問題文も一文章で終わるような簡単な問題はなく、ユースケースをしっかり把握していることが求められる印象でした。 問題文は多少違えど、特に以下の本質的な理解を問う問題が、3割～4割近く出題された気がします。要チェックですね。 NATゲートウェイを使ったプライベートサブネットからのインターネットアクセス方法 VPC内からのインターネットを経由しないVPCエンドポイントを使ったアクセス S3での静的ウェブサイトホスティング & CloudFrontでのキャッシュ高速化 EBSやEFS、S3のストレージサービスの場面の使い分け SQSを使ったマイクロサービス連携 受験後の感想 問題文と選択肢が与えられると答え分かるんだけどねぇという感じです。 実務の場面で使いこなせて、べスプラ構成を設計できるようには、やはり自分で手を動かして実装してみるのが一番だなあと感じました。 AWS公式からもハンズオンが公開されているので、こちらで実際に手を動かして学ぶのもおススメです。 https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/