ECSにサービスをデプロイする場合、ecspresso を含めいろいろなツールがあり情報も多いですが、タスクのスケジューリング（cron的なもの）に関してはあまり情報が見つかりません。みんな定期実行どうしてるんでしょう 探してみると、ecspressoにインスパイアされた ecschedule というツールがありました。 実際に使ってみてなかなか良かったので、ecscheduleの使い方と注意点を紹介します。 インストール ecscheduleはGo製なので、go get か自分の開発環境にあった実行ファイルをパスの通った場所に置けば動きます。また、READMEには書いてありませんが、Macを使っている方はHomebrewでインストールできます。 $ brew install Songmu/tap/ecschedule GUIでスケジューリング設定したものをダンプする ecspressoと同様に、AWSの管理コンソールで設定したものをecscheduleの設定ファイル（YAML）として吐き出せます。GUIでの設定方法は公式サイトを参考にしてください。 今回は、このような設定を登録してみました。この設定をダンプしてみます。 $ ecschedule dump --cluster sample --region ap-northeast-1 > ecschedule.yaml $ cat ecschedule.yaml 実行結果 region: ap-northeast-1 cluster: sample rules: - name: test scheduleExpression: cron(0 3 * * ? *) taskDefinition: [TASK_DEFINITION] launch_type: FARGATE platform_version: LATEST network_configuration: aws_vpc_configuration: subnets: - [SUBNET_ID_1] - [SUBNET_ID_2] - [SUBNET_ID_3] security_groups: - [SECURITY_GROUP_ID] assign_public_ip: ENABLED 設定に変更がある場合、ecschedule.yamlを変更して ecschedule apply で適用できます。 $ ecschedule -conf ecschedule.yaml apply -rule test # test という名前のスケジュールルールのみ対象 $ ecschedule -conf ecschedule.yaml apply -all # すべてのスケジュールルールが対象 楽ちんですね 注意点 ecspressoと同じような感覚で使えて大変良いのですが、いくつか注意点があります。 1. タスク定義を登録する機能はない ecspressoとは異なり、ecscheduleにはタスク定義を登録する機能はなく、スケジューリングの設定のみ行うことができます。タスク定義は別途行う必要がありますが、ecspressoで作成したタスク定義のJSONファイルを流用し、aws-cliで登録するという方法があります。 $ aws ecs register-task-definition --cli-input-json file://ecs-task-def.json 2. 起動タイプを指定しないとEC2になる ecschedule自体の問題ではないと思いますが、設定ファイルで起動タイプを指定しないとEC2になります。ECSクラスタでFargateのみ使うようにしている場合、起動タイプがEC2だとタスクを起動できず、起動に失敗したログも（おそらく）出ません。 3. タスク定義にコンテナが1つしかない場合、1コマンドしか実行できない ECSでは当たり前な気もしますが、KubernetesのCronJobを使っている方だと勘違いしてしまうかもしれません（私のことです）。CronJobがPodを起動するのとタスク定義からタスクを実行するのとでは概念が違うので、要注意です。 4. 設定ファイルからルールを削除してapplyしても、ECSクラスタには適用されない ecscheduleコマンドではルールを削除することができないので、 GUIで削除する aws-cliで削除する 設定ファイルに disabled: true を追加して無効にする このような対応を行う必要があります。 5. Cron形式で記述する場合、UTCの日時で設定する All scheduled events use UTC time zone and the minimum precision for schedules is 1 minute. 日本在住だとついついJSTで書きがちですが、UTCで書きましょう。 最後に ECSのデプロイは、ベストプラクティスがイマイチ固まっていないような印象です。運用に応じて適切なツールを選びたいですね。

Slack Appを使用し、さらにサーバレスで実装してみました！今回使用するのはPython、AWSのLambda、API Gatewayです。 　API GatewayとLambdaの設定 　　AWSのLambda、API Gatewayについては過去のhttps://qiita.com/ymktmk_tt/items/7ad4e63e62795bb2418b に細かいことを書いてあるので同じように設定してみてください。 　　では、始めます ！！ 　Slack Appを作成 　　https://api.slack.com/ にアクセスして「 Create a custom app 」 を押して、「 Create New App 」を押す。すると下の画像のような画面に遷移するかと思います。 　　そして、「 App Name 」と「 Development Slack Workspace 」を入力し、「 Create App 」をクリックするとアプリケーションが作成されます 　Slack Appの設定 その① -- 「 Event Subscriptions 」 　Lambda関数のlambda_fanction.pyに一旦下記のように記述してください。Slack Appとの連携確認が必要なためです。 lambda_fanction.py import json def lambda_handler(event, context): return json.loads(event['body'])['challenge'] 　そして、Slack API メニューから「 Event Subscriptions 」を選択 「 Request URL 」にAPI GatewayとLambdaを設定するで作成したAPI Gatewayのエンドポイントを入力します。しばらくして「Verified」になればOKです！ 少し下にスクロールして「 Subscribe to Bot Events 」に「 channel_created 」のイベントを追加します 　Slack Appの設定 その② -- 「 Install App 」 Slack API メニューから「 Install App 」を選択 「 Install to Workspace 」をクリック！ アプリケーションインストールの確認画面が表示されるので問題なければ「 Allow 」をクリックします。 インストールされるとSlackの画面でアプリケーションが起動しているのを確認できます。 　　プログラムの作成 Botのtokenが必要なのでそれをメモしておきます。Slack API メニューから「 OAuth & Permissions 」を選択して「 Bot User OAuth Access Token 」に書かれているtokenをコピーします。 そして、少しスクロールしてこの3つを追加しましょう。 さて、いよいよ Lambda関数にコードを書いていきましょう！ lambda_fanction.py import logging import os import json import urllib.request logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): logger.info(event) channelName = json.loads(event['body'])['event']['channel']['name'] channelId = json.loads(event['body'])['event']['channel']['id'] url = "https://slack.com/api/chat.postMessage" headers = { "Content-type" : "application/json", "Authorization" : "Bearer "+ os.environ['TOKEN'] } data = { 'channel': '通知したいチャンネルID（このAppが存在する）', 'text': '新しいチャンネル: ' + '#' + channelName, 'link_names' : 1, } req = urllib.request.Request(url=url, data=json.dumps(data).encode('utf-8'), method='POST', headers=headers) with urllib.request.urlopen(req) as res: logger.info(res.read().decode("utf-8")) 　　試してみよう 通知したいチャンネルに作成したアプリケーションを追加しましょう。 できました！　slack API ドキュメントを見るとさらに色々な機能をつけることができます。もしエラーが出てしまってもドキュメントに解決方法が載っていますよ！ 　　参考記事 ・ https://coxcox.hatenablog.com/entry/2017/08/16/163719 ・ https://api.slack.com/events/channel_created ・ https://api.slack.com/methods/chat.postMessage#arg_link_names

プログラミング勉強日記 2021年4月16日 リージョンとは 　regionは日本語で「領域」という意味。AWSは世界を複数の"リージョン"に分割して、リージョンごとにクラウドコンピューティングサービスを提供している。 　日本の場合、東京リージョンと大阪ローカルリージョンの2種類存在する。 　それぞれのリージョンは独立したインフラ拠点で、あるリージョンで障害が発生した場合でも他のリージョンでは影響がないように設計されている。 　基本的にはアプリとして1つのシステム・1つのインフラを使う場合は1つのリージョン内で完結させる。ただ、リージョンをつなぐ方法もあって、隣接するリージョン間は広帯域の専用ネットワークで接続できる(後で詳しく記述する)。使い方としては、東京リージョンでインフラを構築して、物理的なバックアップを大阪ローカルリージョンに送っておくことで、地震や火災などの万が一のときにも、大阪ローカルリージョンの方で復帰させることもできる。 　リージョンによっては使用できるAWSサービスの種類と料金が異なる。1番最初に接続が提供されるのは米国東部(バージニア北部)のリージョンなので、東京リージョンでは最新の機能が使えない。 リージョンの選択方法 　データやシステムに関する法律や社内規定を考慮したうえで、基本的には身近なリージョンを選択してAWSシステムを構築する。基本的には、事業継続性計画(BCP)などの対策のため、データや予備システムとして別のリージョンを利用する。ただし、リージョンのある国の法律に影響される可能性も考慮する。 　中国の場合、中国政府の要請に従ってAWS中国はデータを提示する義務が生じる。また、中国内のデータの持ちだす制限も設けられる。 リージョン間の連携 　リージョン間では、専用線説zくしてレプリカが作成できるようになっている。連携方法としては以下の7つを紹介する。 1. AWS Direct Connect Gateway経由で接続 　AWS Direct Connect Gateway経由で接続する方法がよく使われる方法。 2. S3リージョン間のレプリケーション 　ストレージサービスのS3をリージョン間でレプリケーションしてバックアップする。 レプリケーションとは、あるコンピュータやソフトウェアの管理するデータ集合の複製（レプリカ）を別のコンピュータ上に作成し、通信ネットワークを介してリアルタイムに更新を反映させて常に内容を同期すること。 引用文献：IT用語辞典 レプリケーション 3. インターリージョンVPC Peeringで接続 　リージョンが違うVPC間でペアリング接続・別々のVPCをつなげる。(VPCについてはこちらの記事で詳しく扱ってる。) 4. EC2リージョン間でのAMIコピー 　別リージョンにあるEC2同士でEC2のイメージ(OSのようなもの)をリージョン間でまたいでコピーする。 5. RDSリージョン間でのリードレプリカ 　データの保存・バックアップを行う。 6. Route53 DNSフェイルオーバー 　フェイルオーバーの仕組みをリージョン間で作る。フェイルオーバーは、稼働中のシステムに問題があってシステムやサーバーが落ちてしまったときに自動的に待機システムに切り替える仕組みのこと。 7. DynamoDBリージョン間でのレプリカライブラリ 　 参考文献 レプリケーション 【replication】

概要 CloudFrontにおけるログをAthenaを使いクエリするといったことはよくあると思います。 その際にdate, timeのカラムから日付を絞りクエリする際にUTC時間を気にしなければなりません。 今回は、そんな時に使うクエリをいくつか用意してみました。 AthenaにCloudFront テーブルを作成する 下記のDDLステートメントをコピーしてAthenaのコンソール(クエリエディタ)に貼り付け(Run Query)をします。 ちなみに、下記のDDLは公式ドキュメントのものをそのまま引用しています。 CREATE EXTERNAL TABLE IF NOT EXISTS default.cloudfront_logs ( `date` DATE, time STRING, location STRING, bytes BIGINT, request_ip STRING, method STRING, host STRING, uri STRING, status INT, referrer STRING, user_agent STRING, query_string STRING, cookie STRING, result_type STRING, request_id STRING, host_header STRING, request_protocol STRING, request_bytes BIGINT, time_taken FLOAT, xforwarded_for STRING, ssl_protocol STRING, ssl_cipher STRING, response_result_type STRING, http_version STRING, fle_status STRING, fle_encrypted_fields INT, c_port INT, time_to_first_byte FLOAT, x_edge_detailed_result_type STRING, sc_content_type STRING, sc_content_len BIGINT, sc_range_start BIGINT, sc_range_end BIGINT ) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LOCATION 's3://CloudFront_bucket_name/CloudFront/' TBLPROPERTIES ( 'skip.header.line.count'='2' ) クエリしてみる 今回は２パターン用意しました。 ①: 特定の日付(1日)のみに絞りクエリする SELECT * FROM cloudfront_logs WHERE uri LIKE '%.mp4' AND ((date = CAST('2021-04-14' AS DATE) AND time >= '15:00:00') OR (date = CAST('2021-04-15' AS DATE) AND time < '15:00:00')); ②: 複数日付を指定し、その間にある条件でクエリする SELECT * FROM (SELECT from_iso8601_timestamp(date_format(date, '%Y-%m-%dT') || time || 'Z') AT TIME ZONE 'Asia/Tokyo' jst_date, time, uri FROM cloudfront_logs WHERE "date" BETWEEN DATE '2021-02-01' AND DATE '2021-04-15' GROUP BY date, time, uri) WHERE "jst_date" BETWEEN DATE '2021-02-01' AND DATE '2021-04-15';

なぜ受けようと思ったのか 会社の勉強会にて触れる機会があり、AWSの案件に入りたくなったから。 実際にAWSのプロジェクトに参画している方より勧められたから。 投稿者について 業界未経験で入社。今年3年目。 実際の業務では主にhtml、css、jsを使っており、週次で開催される社内の勉強会でDockerやAWSの一部サービスについて勉強していました。 使用した教材・コスト ・これだけでOK! AWS認定クラウドプラクティショナー試験突破講座（豊富な試験問題290問付き）1200円（セール時価格） ・これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）1300円（セール時価格） ・【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）1340円（セール時価格） ・一夜漬け AWS認定ソリューションアーキテクト アソシエイト[C02対応]直前対策テキスト 単行本 2420円 ・AWS CloudTech無料問題集 無料 ・SAA-P02: AWS 認定ソリューションアーキテクト - アソシエイト - 模擬試験　4400円(2200円×2回) ・SAA-C02: AWS 認定ソリューションアーキテクト - アソシエイト　16500円 合計27160円 勉強期間 4ヶ月弱　計200時間 ほとんど週末のみ勉強していました。最後まで結構のんびり勉強しました。 教材について udemy ハンズオンはクラウドプラクティショナーの教材でAWSの主要サービスの概要を学び、ソリューションアーキテクトアソシエイトの教材で実際にサービスを使ってどうインフラなどを構築するかを学びました。 模擬試験問題集は2周しましたが、2回くらいしか合格点をとれていません。 文字通り高難易度の模擬試験で、説明文にも「高難易度だから70%以下でも落ち込まないで」と書いています。この文章読んでいなくて本番まで落ち込んでいました。 AWS CloudTech ちょうど勉強をしていた時期に発足したサービスで月額制のサービスとなっています。今回は無料会員登録で実施できる200問の問題のみ利用しましたが、採点が10問ずつで空いた時間などに解きやすかったです。 コミュニティやハンズオンもあるみたいなのでこちらを利用するのもいいかなと思います。 直前対策テキスト ラスト2週間くらいの時に読みました。 内容は試験問題の傾向や練習問題で頻出するサービス、構成に絞っていてかなり実践的な内容でした。 各項目の要点を読んで引っかかる部分があったら解説をじっくり読む、という使い方をしました。 公式摸試 今回はピアソンVUEにて2回受けました。1回目はSAAハンズオンが終わった時点で受け正解率46%、2回目はその1ヶ月後に受けて69%でした。 ちなみに問題内容は1、2回ともほぼ同じでした。 本番試験と同じUIで受けられるので操作に慣れる意味でも1回は実施した方がいいと思います。 試験内容で気づいたこと ・噂通り、一部翻訳が怪しい部分がありました。元の英文を見れば解決します。 　例：集合配置→プレイスメントグループ　など ・基本的に問題文を読み解くのに時間がかかるものが多く、40問目以降は結構疲れていました。 ・練習問題では「～でないものはどれか」といった問題文が結構ありましたが、一切なかったです。 ・複数回答問題が1問しかありませんでした。かなり運がよかったのかもしれません。 ・思っていたより主要サービス寄りでした。EC2やS3、RDS関連の問題がほとんどで、練習問題ほど出てくるサービスの種類は多くないといった感じです。 受験後 受験終了から3時間後、証明書と認定バッチが発行 受験終了から5時間後、スコアレポートが発行

EBSのrootデバイスをgrowpartで拡張しようとしたが、「No space left on device」というエラーで拡張できない時のメモ。 対処方法 エラーを回避するには、一時ファイルシステムであるtmpfsを/tmpにマウントする。 $ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp その後にgrowpart、resize2fsを実行する。 $ sudo growpart /dev/nvme0n1 1 $ sudo resize2fs /dev/nvme0n1p1 最後にアンマウントする。 $ sudo umount /tmp 参考 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html https://aws.amazon.com/jp/premiumsupport/knowledge-center/ebs-volume-size-increase/

はじめに 本日(2021/4/16)、AWS認定ソリューションアーキテクトアソシエイト試験を自宅でオンライン受験しまして、 無事に合格することができました〜✨ エンジニアになって1年半が経ち、 毎日30分ゆっくりAWSの勉強を続けてきていたし、 先週にはAWS認定クラウドプラクティショナーの試験にも合格していたので、 このイイ流れを活かして、ノリで取っちゃおうという作戦でした。 受けるまでの準備、当日の出来事、心境等をもろもろ綴りたいと思います〜 TL;DR 試験の予約方法 勉強方法 当日の流れ 受けてみた感想とハプニング AWS認定試験 - 予約方法 予約方法は、AWS認定クラウドプラクティショナー試験を受験した時の記事にまとめましたので、 こちらご参照ください〜 AWS認定試験 - 勉強方法 勉強方法はシンプルです。 自分は 参考書を３回読む。 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 (日本語) 単行本（ソフトカバー） – 2019/1/18 1回目：ざーっと全てに目を通し、なんとなく頭に入れる。 2回目：一つ一つのセクションをゆっくり読んで、概念を理解する。 3回目：確認問題があるので、解いてわからないところを参照しながら、もっとじっくり読み込む。 ※内容としては少し古くなっているところもあるかもです。 whizlabでPractice Testsを購入し(1000円くらい)、全テスト8つ+セクションテストを4周くらいしました。 ・毎朝のルーティーンは、30分間。5問解いて解説を読み、前日解いた5問を復習と言った流れです。 ・解き方は、「各問題を解く → 回答を選択直後に答え合わせ → 解説をその場で読み理解する」の繰り返し。 ・試験1週間前は、模擬テストを時間を測りながら65問一気に解いて、解き終わったら、間違った問題の解説を読むって感じです。 最終的には、90%の正答率を模擬テストで出せるくらい理解を深めました。 「継続は力なり」を実感。 AWS認定試験 - 当日の流れ Pearson VUEで自宅受験する場合、 チェックインが試験開始の30分前にあります。 自分は午前11時に予約しました。試験時間は通常130分です。 (※自分は、ESL +30申請したので、160分間で実施。) 時刻 アクション 7:10 起床 7:20 朝食(コーンフレーク)＋リポビタンD 7:30 ~ 8:30 ボッとする、嫁と雑談、決意を込めて祈る(厨二) 8:30 ~ 9:00 お昼の煮込みうどん作る(うまかたぁぁぁ) 9:00 ~ 9:10 あずきのチカラ アイマスクで目を温めて回復させる 9:10 ~ 9:15 部屋と環境の最終セットアップ 9:15 ~ 10:25 もう一度参考書の問題を解く＋100マス計算をしてウォーミングアップ 10:30 チェックイン 10:45 試験開始 13:30 試験終了 ※早く試験を配布されたから、早く開始できた 受験の注意点と事前準備のススメ OnVUE 試験を受ける際のヒント に記載されてますが、 とにかく自宅受験の条件がめちゃめちゃ細かい、かつ厳しく、 試験中ずっと試験官監視されながらレコーディングされるなど、 束縛がめちゃくちゃ激しいので、覚悟して望むこと。 メンヘラかよwww 「備えあれば憂いなし」です。 びっくりした条件 一部始終レコーディングされる、そのウェブカメラ内に常に自分の顔が映ってないとダメ 外れたら試験強制終了 第三者が試験スペースに侵入したり映り込んだらダメ 映り込んだりしたら即試験強制終了 プライベート空間にも関わらず、試験中は問題文を声に出して読んではダメ 試験官にとって耳障りだから 自宅のプライベートな受験スペースを試験官にウェブカメラ通じて全部晒します360° 部屋のポスターとかダメ 上着系も手に触れるエリアにあるとダメ 腕時計、財布とかも持ち込み禁止 デュアルモニターは禁止 前夜にできる限りセットアップしておく 部屋をキレイに整理整頓して、何も試験に影響を及ぼすようなものは置かないことが大事 システムテストは絶対にやっておくべき。 onVUEアプリをダウンロードして、マイクと通信環境、カメラの調子を確認します。 チェックイン時にダウンロードするのは時間がかかるから絶対にオススメしません。 会社のパートナーアカウントに自分の認定を紐づける 会社がパートナーアカウントを持っていた場合、 自分の認定証を会社のパートナーアカウントに紐付けられるので、 こちらの記事を参考にして、どんどんアピールするといいと思います。 母国語が英語以外の人が英語で試験を受けると+30分申請ができる 実際にスケジュールを予約する前に、「試験での配慮希望の申請」ボタンをクリックしてESL +30 MINUTESの申請をしたら、本番のテストで見事30分延長されてました！ 30分のゆとりがある分、心の余裕につながり、見直しの時間も確保できた。 なんという高待遇✨ Q.オンライン監督試験では特別な配慮を受けることができますか。 A.英語を母国語としない受験者が英語のオンライン監督試験を受験する場合は、「ESL +30」により試験時間を 30 分延長できます。試験を予約する前に、AWS 認定アカウントを使用して、この延長をリクエストする必要があります。 参照元：Pearson VUE Additional Info AWS認定試験 - 受けたみた感想とハプニング 全体的な感想として、 オンラインで受けるAWS認定試験は、２回目の経験だったので、 クラウドプラクティショナーを受けた時よりかはスムーズかつ、全体的に落ち着いて進めることができました。 まあただやっぱり、時間に追われていたり、神経を使ったりするので、非日常過ぎて少し疲れました。 ただ受かったことはものすごく嬉しいです！！✨ 前回の試験官より少し入念に部屋のチェックをしてくる人だったため、360°ビデオで部屋中を映してもなかなかOKしてくれず3周くらい回転しました。（...コード絡まりかけるw） またパソコンのウェブカメラで直持ちして撮ってるので、曲芸師並みの角度から机の上に何もないことを証明するために、必死で撮影しました。 なかなか面倒だったw 試験の言語は、自分は英語で受けました。 whizlabのアソシエイトの模擬問題の問題文とテイストが結構似ていて、とっつきやすかったです。 クラウドプラクティショナーの時よりも、文章の構成や使われる単語など、シンクロ率高めで、親和性高めでした。 試験開始はやはり緊張からかすこしテンパってたけど、開始から20分くらい経つと、だんだん落ち着きを取り戻し、本調子で受けられるようになりました。 試験時間は160分間で（ESL +30の事前申請したので）、110分くらいで問題を解き終わり、残り50分は前半テンパって解いてしまっていた回答の見直しと修正をしました。 試験開始時刻は11時でしたが、試験を配布されたのが、想定より早く、その分試験を早く実施することができました。10時45分くらいには開始してたかな〜 問題の傾向 クラウドプラクティショナーの問題と比べるとやはり、 問題の文章量が長く、AWSの構成や設計に関する、より踏み込んだ内容と用途に関する問題が多い気がしました。 お客さんが困った時の課題解決シチュエーションであったり、オンプレミスからクラウドに移行したいときにどうするか、可用性+コスト+パフォーマンス+セキュリティ+オペレーションが混ざり合うみたいな問題が中心だったように思います。 前回クラウドプラクティショナーを勉強した時に、浮ついていた基礎が固り、 その上にアソシエイトの知識を上積みした形なので、あやふやなことは極力少なくすることが大事なのと やはり基礎問題に挑戦するのも捨てたもんじゃないなと実感しました。 前回チェックイン時にテンパったので極力ブラウザ上の何かを触らないことに徹する 前回クラウドプラクティショナーを受けた時に、試験専用ブラウザがフリーズして、マックの矢印アイコンがずっとくるくるし続けるというプチハプニングが発生し、チェックイン時間中15分くらい何もできない状態が続きました。 onVUEアプリのブラウザ自体が、かなり重いらしく（重くしてる？）、想定されていないコマンドがなされると処理ができない仕様になっているっぽくて、かなり困った。(Macとの相性とかもあるのかな？？？) 試験官（プロクター）とチャットでやり取りするんだけど、そのチャットモーダルが画面の左過ぎる場所に出現して、 移動させたい気持ちで溢れるのですが、下手に移動したりするのはやめた方がいいですねえ。 触らない方がいいです。あれ移動させると、アイコンくるくるし始めます。 今回も、試験問題が配布された後、試験官にチャット打った時に、アイコンがくるくるして、一分間くらい試験官とやりとりができませんでした。 移動させたり、「あれ、テキストがチャットに反映されないなあ」ってので追加でタイピングをしてしまうと、よりフリーズを悪化させる原因になるので、注意が必要。 自分は、今回そのくるくるがほとんど起こらずに、スムーズに試験に移ることができました。 試験中に表示されるレコーディングのタスクバーは試験開始直後に煩わしくないところに移動させておく 問題を解いてる最中に、「レコーディングされている自分が見えるタスクバー」みたいなのが画面センター上部にあって、前回、問題を読んでいる時に毎回自分の姿が目に写り、煩わしかったので、 試験開始直後に、それをドラッグして場所を移動させちゃいました。 大体そういうのを移動させるとフリーズ現象が起こるので、極力ダメージが少ないタイミングで、それを行いました。 無事に狙い通り、あまりフリーズも起きずに、煩わしさも解消され、試験に集中できました。 繊細なonVUEシステムから開放されたい人はやっぱり、 テストセンターに行って受けるのが一番かもしれないですね(⌒▽⌒) スコアは何点だ！？ とりあえず試験終了後にCongratulations, Passと言われたので、ホッとしてますが、 スコアが来るまでに、最大で5営業日かかるみたいです。 気長に待とう(☝︎ ՞ਊ ՞)☝︎ 前回同様、後ほどキャプチャあげます〜 まとめ 次は、AWSデベロッパーアソシエイツをとるぞ！ （本当はソリューションアーキテクトプロフェッショナル目指したい。） ＼＼\٩( 'ω' )و //／／ 以上、ありがとうございました！

はじめに AWS サービス別資料 にある Amazon CloudFrontの概要 の資料をもとに社内で勉強会を実施しましたので、そのメモを共有します。 Amazon CloudFrontについて 概要 AWSが提供するCDN（Content Delivery Network）サービス 世界中のエッジにオリジンのキャッシュが展開する リージョンによらず世界中のアクセスからのレスポンスを改善し、オリジンの負荷を削減 構成要素 オリジン キャッシュ元のWebサイト・サービス エッジロケーション 「エッジ」はIoTでも使われるエッジコンピューティングのエッジと同じで、利用者の近くでコンピュータ資源を使うことを指す エッジロケーションは世界に約200拠点ある。リージョン、AZの中または近くにある（はず） グローバルサービス（Route53とか）も AWS エッジロケーションでホストされている ユーザに近い拠点で配信することになり、レイテンシ（通信遅延）が減少し、ユーザ体験を高めることにつながる リージョナルエッジキャッシュ 最近はエッジロケーションとオリジンの間にリージョナルエッジキャッシュという大容量キャッシュ層が挟まれていて、スペック向上している https://dev.classmethod.jp/articles/cloudfront-regional-edge-cache/ が参考になる 「ユーザの近く」はどうやってわかる？ 謎テクノロジー 資料p.15の図によると、CloudFront専用のDNS（機械学習込み）で99.8%の精度で位置および国情報がわかるらしい 機能 以下のHTTP/HTTPSメソッドに対応 GET, HEAD, OPTION(選択可能) (Cacheモード) PUT, POST, DELETE, OPTION, PATCH (Proxyモード) 　→ キャッシュはされず、 オリジンにフォワードする キャッシュ時間 デフォルトは24時間 キャッシュコントロールヘッダー（デフォルトTTL、最小TTL 、 最大TTL） の 3 つの値でコントロール可能 最小TTL = 0秒 の場合とそれ以外の場合でCache-Control no-cacheの挙動が違うため注意 キャッシュの無効化 コンテンツごとまたはワイルドカード指定可能。（ただし料金はかかる） ヘッダーをオリジンへ転送 任意のヘッダーを付与することが可能 CroudFront独自ヘッダーとして、接続プロトコル、デバイス判定、地域・国判定した結果をオリジンに送ることが可能 Cookie をオリジンへ転送 Cookieもキャッシュする セッション情報などキャッシュできないものに絞ってホワイトリストに追加してフォワードする クエリパラメータ値をオリジンへ転送 クエリパラメータと値もキャッシュする languageなどキャッシュできないものに絞ってホワイトリストに追加してフォワードする カスタムエラーページの生成 オリジンで5xxエラー発生時にS3のカスタムエラー静的HTMLを表示する エラーキャッシュ期間はデフォルト5分 タイムアウト オリジンの読み取りタイムアウト（デフォルト30秒、4秒〜60秒まで指定可能） キープアライブタイムアウト（デフォルト5秒、1秒〜60秒まで指定可能） オリジンフェイルオーバー プライマリオリジン、セカンダリオリジンを指定可能 オリジンシールド（オリジンへの到達の前に必ず通過する配信拠点）を設定可能 セキュリティ 地域・国制限 - クライアントの地域情報を元にアクセス制御できる（ブラックリストまたはホワイトリスト） 署名付きURL/Cookie - セキュリティ要件が厳しいデバイス - オリジン間で使える？ AWS WAF、AWS Shield - オプションでCloudFrontの前段に設置できる レポート・統計 CloudWatch連携あり Google Analytics的に分析用途にも使える？ アクセスログの詳細解析用としてAmazon Athena、QuickSightに流す用途もあり 性能 他CDNよりもトラフィック減少 p.20の図は悪いグラフ図（赤線が同じ位置にない） 料金体系 AWS EC2やS3のオリジンからCloudFrontのエッジへの通信量は無料（逆はかかる） データ転送アウト（GBあたり）とリクエスト（10000件あたり）とオリジンへのデータ転送アウト（GBあたり）でそれぞれ料金発生 キャッシュの無効化リクエスト（最初の1000ファイル/月は無料、それ以降はかかる） Lambda@Edgeについて 概要 CloudFrontのエッジで展開（ディストリビューション）されて動作するAWS Lambda（Node.js、Python） 4つのCloudFront周辺のイベントでLambdaをトリガーできる1 CloudWatchのメトリクスもある まとめ CloudFront は世界中のエッジにオリジンのキャッシュが展開されることでユーザーへのレスポンスを改善し、オリジンの負荷を削減 CloudFront は AWS WAF との組み合わせや、組み込みの DDoS 対策により、高いセキュリティを実現 ログ & レポート機能でアクセス傾向分析も可能 大容量の画像・動画配信や大量アクセスがあるサイトでの活用が有用 小規模でも WAF/DDoS 等のセキュリティ対策が必要なサイトで有用 https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-cloudfront-trigger-events.html ↩

VPC Flow LogsをすぐにAthenaでクエリできる。そんな機能が出ました What's New 公式ドキュメント やってみよう 最初の状態 VPC Flow LogsをS3に出力する設定がされてる状態とします。手順は以下にあるのでご参照ください 公式(ちょっとこまかい) https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs-s3.html クラメソさんブログ https://dev.classmethod.jp/articles/vpcflowlogs_to_s3/ 任意のS3バケット作成 S3バケットを１作っておきます。これは今回のAthena統合で使うCFnテンプレートやAthenaクエリ結果の保存先バケットとして使います。 Athena統合 Athena統合スタート 対象のVPCにチェックを入れ 下部のタブで"フローログ"をクリック 作成したフローログ。ここでは"aes-siem-flowlogs"にチェックを入れ その少し右上の[アクション]をクリックし、[Athena統合を生成]をクリックする Athena統合を生成画面 以下を入力し、右下の[Athena統合を生成]をクリック 「ロード頻度のパーティション」を指定。ここでは"毎日"を指定 「パーティションの開始日」「パーティションの終了日」を指定。ここでは画面の通りの日付を入力。これはAthenaが認識するパーティションになります。yyyy/MM/ddでパーティションが切られてるので、日付ごとにスキャン出来てコスパがいい形です。 「CloudFormationテンプレートS3バケット」を指定。ここでは事前に作成したS3バケットを指定します。 「クエリ結果S3バケット」を指定。ここでは事前に作成したS3バケットを指定します。 プレフィックは必要に応じて入力してください。上記で指定したバケット配下のディレクトリになります。 VPCの画面に自動で戻る VPCの画面に自動で戻ります。そしたら右上に[CloudFormationスタックの作成]ボタンが出てるのでそれをクリックする CloudFormation実行 クリックするとCloudFormationの画面に遷移します 最初の画面はそのまま[次へ] 次の画面でスタック名を任意の名前入れて[次へ]。ここではtmp-vpcとしました。 次の画面はそのまま[次へ] 最後の画面は"AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。"にチェックを入れて、右下の[スタックの作成]をクリック 数分すると完了します。 完了したらAthenaを開く Athenaを開いたら、先程のCloudFormationの実行で作成されたAthena ワークグループを選択します。(興味があればCloudFormationテンプレートも読んでみてください) 手順は、Athenaの画面から右上か真ん中の上部辺りの"ワークグループ"を選びます 長い名前のワークグループがあります。それが今回作成されたものです。それにチェック入れて、画面上部の[ワークグループを切り替える]をクリックします。2回くらい注意事項がポップアップしますが[次へ]などクリックして進めます AthenaでVPC FlowLogsをクエリ 作成されたデータベースを選択し、該当のテーブル(多分1つしかないと思います)を対象にクエリを実行します。 画面では、対象のテーブル名の右横にある点々をクリックし、"テーブルのプレビュー"をクリックし、select...limit 10を実行しています。 定義済みクエリを実行 Athenaの画面の上の方にある"保存したクエリ"をクリックする CloudFormationによって自動作成された定義済のクエリが出てきます。 対象のクエリをクリックすると、クエリが入力された状態でエディタの画面に遷移します。あとはクエリ実行するだけです このクエリだと、トラフィックが多い送信元IPアドレスを、トラフィック量の多い順番で表示してます。 VpcFlowLogsTopTalkers –最も多くのトラフィックが記録された50個のIPアドレス。 このクエリだと、SGやNACLで拒否されたIPアドレスのリストを拒否された数でソートして表示しています。 VpcFlowLogsRejectedTraffic –セキュリティグループまたはネットワークACLに基づいて拒否されたトラフィック。 事前定義クエリはこんな感じです VpcFlowLogsAcceptedTraffic –セキュリティグループとネットワークACLに基づいて許可されたTCP接続。 VpcFlowLogsAdminPortTraffic –管理Webアプリポートに記録されたトラフィック。 VpcFlowLogsIPv4Traffic –記録されたIPv4トラフィックの合計バイト数。 VpcFlowLogsIPv6Traffic –記録されたIPv6トラフィックの合計バイト数。 VpcFlowLogsRejectedTCPTraffic –セキュリティグループまたはネットワークACLに基づいて拒否されたTCP接続。 VpcFlowLogsRejectedTraffic –セキュリティグループまたはネットワークACLに基づいて拒否されたトラフィック。 VpcFlowLogsSshRdpTraffic –SSHおよびRDPトラフィック。 VpcFlowLogsTopTalkers –最も多くのトラフィックが記録された50個のIPアドレス。 VpcFlowLogsTopTalkersPacketLevel –最も多くのトラフィックが記録された50個のパケットレベルのIPアドレス。 VpcFlowLogsTopTalkingInstances –トラフィックが最も多く記録された50個のインスタンスのID。 VpcFlowLogsTopTalkingSubnets –最も多くのトラフィックが記録された50個のサブネットのID。 VpcFlowLogsTopTCPTraffic –送信元IPアドレスに対して記録されたすべてのTCPトラフィック。 VpcFlowLogsTotalBytesTransferred –最も多くのバイトが記録された50ペアの送信元IPアドレスと宛先IPアドレス。 VpcFlowLogsTotalBytesTransferredPacketLevel –最も多くのバイトが記録されたパケットレベルの送信元IPアドレスと宛先IPアドレスの50ペア。 VpcFlowLogsTrafficFrmSrcAddr –特定の送信元IPアドレスに対して記録されたトラフィック。 VpcFlowLogsTrafficToDstAddr –特定の宛先IPアドレスに対して記録されたトラフィック。

１．はじめに 運営しているサイトからのメールが届かないという事象の調査と対応を記載する。 環境構成(AWS) Route53(DNSサーバー) CloudFront→ELB→EC2(メールサーバー兼WEBサーバー) ２．どう調査したか ①ログの調査 まずメールの送信ログを調査。ブラックリストで弾かれているという内容が記載されていた。 ②ブラックリストの確認 以下のブラックリストを確認すると、SPAMHAUSのブラックリストにメールサーバーのIPが載っていた。 ・SPAMHAUS ・proofpoint ③解除申請 一時的な対応としてSPAMHAUSにブラックリスト解除申請を出し、数分後解除されたことを確認。 ④原因調査 ブラックリストに載った原因を調査開始したが、SPFレコードとPostfixの設定に問題はなさそうだった。 　・Route53のSPFレコード：以下で設定されていたため、問題なし v=spf1 +ip4:XXX.XXX.XXX.XXX/32 +ip4:YYY.YYY.YYY.YYY/32 +ip4:ZZZ.ZZZ.ZZZ.ZZZ/32 ~all 　・メールサーバのPostfix設定(/etc/postfix/main.cf)：\$myhostnameと\$mydomainが一致しているため問題なし ⑤追加調査 さらに調査を進めると、以下の3つで整合性がとれていないとブラックリストに載る可能性がある模様。 　１．メールサーバーのIPから検索したドメイン(nslookup の逆引き) 　２．↑でヒットしたドメインから検索したメールサーバーのIP(nslookup の正引き) 　３．メールの送信元アドレスに設定されているドメイン 　　　※1のドメインは、3のドメインもしくはサブドメインである必要がある ⑥IPでドメインを検索(逆引き) メールサーバーのIPでドメインを検索(逆引き)すると、EC2自体のデフォルトドメインが返ってきた。 ⑦ドメインでIPを検索(正引き) 上述した⑥のドメインでIPを検索(正引き)すると、メールサーバーのIPが返ってきた。 ⑧メールの送信元アドレスを確認 メールの送信元アドレスに設定されているドメインと逆引きの結果が異なっており、不整合が発生していた。 ３．どう対応したか 送信元メールアドレスのドメインはサイトのドメインとなっており、正引きの結果はCloudFrontのIPが返ってくる。そのため新しくサブドメインを作りメールサーバーのIPを割り当てて、逆引きでこのサブドメインを返す。 これにより、正引き/逆引きで送信元メールアドレスのドメインのサブドメインに解決されるようになり、上述した⑤の条件を満たすようにする。 正引きはRoute53のみで対応できるが、逆引きはAWSに申請する必要がある。 ①正引きを設定 正引きをRoute53で設定。 ②逆引きの申請 逆引きのためAWSにメール制限解除申請フォームから申請。 ③設定完了 翌日AWSが設定完了のメールが来たため、nslookupで正引きと逆引きを確認。 数日経過観察したが、再度SPAMHAUSに乗ることはなかった。 ４．まとめ ・ブラックリストに載る理由は、Postfixの設定やTXTレコードだけではない。 ・メールドメインの正引き/逆引きを設定しないといけない。 ・メールサーバーを追加/入替するときには、上記の事を忘れてはいけない。

勉強前イメージ lakeってことはデータ取り込むような場所ってことかな？ 調査 AWS Lake Formation とは AWS Glueの拡張のようなもので AWSでデータレイクを構築・運用するためのマネージドサービスで、 安全なデータレイクを数日でセットアップ出来るのが特徴になります。 データの移動や保管、クリーニング処理を素早く行うことが出来ます。 実体はAWSの各種サービス(s3,IAM,Glueなど)をラップしたものになります データレイクとは？ データをそのまま生データで格納せきるストレージリポジトリで、 非構造化データをそのままの形式で保管することが出来ます。 メリット データレイクをすばやく構築する データの移動、保存、カタログ化、消去をすばやく実行できます。 また、S3内のデータを頻繁に使用されるクエリ用語で整理し、まとめ、効率性を向上します。 セキュリティ管理を簡素化する セキュリティ、ガバナンス、監査のポリシーを一元で 1つの場所で定義出来るので、サービスごとに行う必要がありません。 また、定義したポリシーは全体に適応できます。 データにセルフサービスアクセスを提供する データカタログを構築することによって、分析対象のデータセットを適切に検索できます。 用語(各コンポーネント)の説明 データレイク データカタログの実体としてs3に保管されたデータ 構造化データも非構造化データもどっちも格納できる データアクセス データへのアクセス権限を管理するもの IAM ブループリント データレイクにデータを格納するためのテンプレート ワークフローを作成できる ワークフロー ブループリントから生成される関連ジョブの格納先 実体はAWS Glueのクローラーとトリガー データカタログ メタデータストアで、メタデータでデータを管理 実体はそのままGlueのデータカタログ 勉強後イメージ s3とかIAMを駆使してデータレイクを作ったサービスって感じ？ 元のAWS Glueがわからんからぴんとこないかも 参考 AWS Lake Formation AWS Lake Formationの概要と使用するメリットとは？ AWS Lake Formationのチュートリアルをやってみた！ 20191001 AWS Black Belt Online Seminar AWS Lake Formation

AWSのSESを使っている本番環境で急にメールが 「たまに」 送られなくなった。 ログにはこんなメッセージが。 [_lastResponse:protected] => Array ( [0] => Array ( [code] => 535 [message] => Signature Version 2 is deprecated for use with SES from March 26, 2021. From that date on, we are progressively rejecting such requests. To resolve the issue, you must migrate to Signature Version 4. If you created your SMTP credentials in the SES Console, please create new credentials and replace the former ones. If you are deriving Signature Version 2 credentials from a IAM user, please start using the Signature Version 4 algorithm: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html ) ) どうやらcredentialsの仕組みが変わったからなんか対応しろと言ってるらしい。 リンク先を見ると難しいことが書いてあるが対応は SESの画面で「Create My SMTP Credentials」ボタンからIAMユーザ再発行して そのID、パスワードに置き換えましょう。それだけで良さそうです。 色々難しいことを書いてあるサイトが多かったけどこれだけでした。

はじめに EventBridgeのターゲットにクロスリージョンのEventBridgeBusを指定できるようになりました。 クロスアカウントのクロスリージョンにも対応可能です。 今までクロスリージョンを設定する際はLambdaやSNSを経由していましたが、その手段をとらずに直接指定できます。 管理が楽ですし、本来必要のないリソースを作成する手間も無くなるので、嬉しいアップデートです。 なお、直接クロスリージョンの別サービスをターゲットにすることはできません。 いつかアップデートされて別のサービスのクロスリージョン対応が実現されると嬉しいですね。 対応リージョン(2021.4.16現在) まだ対応リージョンが少ないので、今後のアップデートに期待です。 ターゲットに指定できるリージョン バージニア北部 オレゴン アイルランド クロスリージョンイベントを送信できるリージョン バージニア北部 オレゴン カリフォルニア北部 バーレーン アイルランド ストックホルム パリ 東京 シンガポール シドニー 作成してみた 東京リージョンでスケジュールしたEventBridgeを作成し、ターゲットにバージニア北部を指定できます。 同一アカウント内のクロスリージョンであれば、ターゲットEventBridgeBusのリソースベースポリシーを設定する必要はありません。 ターゲットに指定できないリージョンを指定すると、このようなエラーが表示されます。 クロスリージョンへのイベント送信をサポートされていないリージョンのターゲット選択画面は以下の通りであり、サポートリージョンと表記が異なることが分かります。 料金 クロスリージョンの利用金はカスタムイベント料金として計上します。 百万件の公開済みカスタムイベントごとに 1.00USDです。

サービスの種類 アンマネージド型構成(UnManaged) スケーリング、耐障害性、可用性を利用者側で設定し管理する必要があるサービス。 設定は柔軟にできるが、その分管理が煩雑になる。 代表的なサービス……EC2(サーバー) マネージド型(Managed) スケーリング、耐障害性、可用性がサービスに組み込まれていてAWS側で管理してくれる。 要はパッケージされているようなものなので管理は楽だが、設定が限定的になってしまう。 代表的なサービス……Route53(DNS) AWSのグローバルインフラ構成 リージョン AZ エッジロケーション の3つから主に成り立っている。 マクロな範囲の順に リージョン > AZ > エッジロケーションとなる。 リージョン 国及びその地域におけるAWS拠点、日本は東京と大阪リージョン。 リージョンとリージョンとは物理的に独立しているので東京と大阪のリージョンは同じ日本の拠点であってもそれぞれ独立した拠点ということになる。 なので、基本的には運用する場合は1リージョン内でということになる。 しかし、例えば極端に言うと障害対策として別リージョンにクローンを作り、運用中のリージョンに障害が起きたら別リージョンに変えるということもできなくはなく、またリージョン間で通信する方法はあるので、一方のリージョンで障害が起きた場合別のリージョンから通信でデータを送ってもらう……ということも珍しいことではない。 例えば東京・大阪リージョンは隣接リージョンなので、広帯域の専用ネットワークで繋がっているので通信は可能である。 リージョンに応じてAWSサービスの利用可能状態や値段が異なる。 例えばバージニアリージョンは機能のリリースがいち早く行われるが、東京は同タイミングでその機能を使うことができなかったりすることがある。 リージョンの選択は要件に応じて、通常はサービスを行うにあたって身近な地域を選ぶ。 例えば拠点が日本である会社のサービスなら東京か大阪がベターということになる。 ただし、拠点が同じ国だとリージョン障害が起きた場合可用性は下がるリスクはある。 反面、拠点と違う国のリージョンを考慮する場合、その国の法律や事情を勘案した上で採用しないといけない。 (ex. 中国の場合、政府に求められたら情報はすべて提供しないといけないなど) 別リーションを選択する例としては、事業継続性計画(BCP)対策やデータ・予備システムを別リーションに作る……つまりは可用性を担保するという目的がある。 *BCP（事業継続計画）とは、企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合において、事業資産の損害を最小限にとどめつつ、中核となる事業の継続あるいは早期復旧を可能とするために、平常時に行うべき活動や緊急時における事業継続のための方法、手段などを取り決めておく計画。 別リーションを作った場合、リージョン間との連携方法は以下のような手法がある。 AWS Direct Connect Gateway経由での接続 インターリージョンVPC Peeringでの接続 EC2リージョン間でのAMIコピー S3リージョン間でのレプリケーション(レプリカを作ってリアルタイム同期する) RDSリージョン間でのリードレプリカ(DBの複製だが読み取り専用) DynamoDBリーション間でのレプリカライブラリ Route53DNSフェイルオーバー(運用中に異常事態が発生した際に、待機している別システムへ切り替える) こうしてみるとすべて可用性・及び信用性に関わるものなのがわかる。 AZ(アベイラビリティゾーン) リージョン内における複数の独立したインフラ拠点。 AZ同士は低遅延(Latency)で常にリンクしているという特徴がある。 1つのAZは物理サーバーの集合によるインフラであり、それを仮想化することでユーザーにサービスを提供する。 つまり、1つのAZのみで障害が起きるとサービスに影響が起こる可能性が高くなるので、複数AZでサービスを構成することで可用性と信頼性を確保するのがベター。 ただし、その場合以下の点に留意する必要がある。 システム間の連携や共有が制限される 単一AZ内でしか共有されない設定が多く、連携するための設定が必要になる エッジロケーション キャッシュデータなどを利用する際のエンドポイントとなる拠点。 CloudFrontやLambdaエッジなどのサービスなどに使われている。 仮想化について 仮想化とは物理的インフラの構成を隠し、仮想化された単位に分けたり、あるいはそれらを統合させて利用できるようにする技術。 基本的な考え方としては1つの大きな物理サーバーがあって、それをストレージにおけるパーテーションのような形で分割してそれぞれリソースを提供するというイメージ。 例えばストレージとして提供された場合、それぞれストレージA,B,C……と個々に利用することもできるし、AとBを合わせて1つのストレージとして扱うようなこともできる。 物理サーバーを仮想化するソフトウエアとしてはVmWare型とハイパーバイザー型とがある。 以下仮想化の例である。 サーバーの仮想化 1台の物理サーバー上に複数のOSを動作させる。 ハイパーバイザー、VmWare、コンテナ(ex.Docker)といった型がある。 ストレージの仮想化 複数のストレージを仮想的に統合して1つの大きなストレージプールとする。 仮想化の段階としてブロックレベルかファイルレベルかといった違いがある。 ネットワークの仮想化 新たな仮想ネットワークの構築や制御をソフトウェアによって動的に実施する技術 SDN、VLANなど デスクトップの仮想化 サーバー上においたPC環境のデスクトップ画面を遠隔地にある接続端末に転送する技術 仮想PC方式やブレードPC方式などがある。 仮想化のメリット 物理サーバーを調達する場合にかかる様々なコストの削減 構成の変更やメンテンナス対応に柔軟性が出てくる セキュリティの向上 仮想化の構成例 仮想化ソフトウェアを使う場合 例えば個人ユーザーにおいて仮想化を使う場合 物理マシン(自分のPC) ホストOS(使うOS) 仮想化ソフトウェア という3つが土台となる。 その上に一例としてEC2インスタンスとして仮想化された ゲストOS ミドルウェア アプリケーション という3つの構成が乗ることになる。 これがDockerだとEC2インスタンスの部分がコンテナとなるので 物理マシン(自分のPC) ホストOS(使うOS) Dockerエンジン ミドルウェア アプリケーション という構成になる。 DockerはゲストOSを用いず、ミドルウェアの部分をコード化してファイルとして共有する。 このファイルによってミドルウェアのインストール及び環境設定が成されるので、誰でも即時に環境再現ができ、作成した環境も配布することで全員が同じ環境を共有できる仕組みになる。 当然、削除もコンテナを消すだけでいいので楽。 語弊はあるがPipEnvにおけるPipFileによる環境再現のようなイメージ(DockerにもDockerFileがある) クラウド 必要に応じて他社所有のハードウェア・ソフトウェア等をネットワークを介して利用するシステム利用形態。 提供されるリソースは主に以下の3つに大別できる。 アプリケーション ex. プログラミングソフトウェア、業務パッケージソフト、フレームワーク ミドルウェア及びOS ex. システム連携・セキュリティ・運用管理システム、Web/アプリケーションサーバー、DB、OS ミドルウェアは共通利用される機能をまとめたソフトウェアを指す インフラ ex. サーバー、クライアント端末、ネットワーク でこのリソース郡をどこまで提供するかで大別したのが前回やったIaaS(インフラまで)、PaaS(ミドルウェアまで)、SaaS(アプリケーションまで全部)である。 クラウドの特徴 5つのサービス構成 オンデマンド・セルフサービス(人を介さずに必要に応じてサーバー、ネットワーク、ストレージを設置・拡大・設定できる) 幅広いネットワークアクセス(ネットワークを通じて各種デバイスから利用可能である) リソースの共有(ハードウェアの使用容量などを複数利用者で共有し、利用者ごとの需要によって動的に割り当てられる) 迅速な拡張性(リソースは必要に応じて手動でも自動でも増減できる) 計測可能なサービスである(稼働状況が常に計測され、利用状況を可視化することでコントロールや最適化ができ、それに応じて従量課金を取ることができる) クラウドの3つの提供形態 まずプライベートなのかパブリックなのかその中間なのかで分かれる。 要はサーバーをどこが持ってて、どう利用されるかという違い。 プライベートな場合 オンプレミス(サーバー自社所有)という形態。 その名の通り、自社でサーバーを所有しその上でハードウェアやソフトウェアを購入して使いシステムを構築する。 自社でハードウェアをコントロールできるが、反面物理サーバーの調達及び環境の構築・運用・維持にコストがかかる。 中間を取る場合 プライベートクラウドという形態 オンプレミスと同じで自社でサーバーを所有しクラウド環境を構築するが、ハードウェア・ソフトウェアは事業部や子会社で共同で利用する。 オンプレミスと比べてより自社資産を効率的に利用でき、下記のパブリックな場合と比べてコントロールも自由が効くがサーバーの調達に関わる問題は残り、クラウドの管理運用が難しいことからクラウドの利点(いつでもどこでも利用ができる)という点から考えるとメリットの低下に繋がる。 パブリックな場合 パブリッククラウドという形態。 外部クラウドによってハードウェア・ソフトウェアともに他社と共同利用する。 柔軟な環境構築・解除が可能である。 運用管理自体を他社に委任でき、システムの調達・構築の自由度が高いがその分リソースから他社依存なので自社コントロールは制限される。

AWSlambdaでMysqlを使ってみた 用途としてWebAPIでデータベースの情報を閲覧したい 過去経験したことのメモ 目次 lambda関数作成 環境変数 モジュール コード ネットワーク 以上の５つのを説明していきたいと思います。 ちなみにcloud９で扱っていきます。 lambda関数作成 cloud９を作成して右の縦のタブに入みたいなマークがあります。 それを、クリックして入+ で nodejs のテンプレートapi-gateway-hello-worldを作成していきます。 環境変数 lambda では環境変数を設定できるらしいんです。 試しに変数を追記します。 追記したら lambda でみてみましょう。 exports.handler = function(event, context, callback) { console.log(event); const response = { statusCode: 200, headers: { "x-custom-header": "My Header Value", }, body: JSON.stringify({message: `Hello ${process.env.name}`}), }; callback(null, response); }; 実行結果 ローカル "body": "{\"message\":\"Hello undefined\"}" リモート "body": "{\"message\":\"Hello test\"}" ここでいうローカルとは、cloud９に環境下 のことです。 リモートは、lambdaの環境下 だと思います。 process.env は、OSの環境変数を指しているので動作環境が違えば、変数は、異なってきます。 モジュール 様々な処理を行う時、外部のライブラリーを使用することは、当たり前のように行われます。 Pythonなら　pip node なら　npm でインストールします。 今回は、node で進めていきます。 npm init npm i mysql 上記のコマンドを実行すれば任意にディレクトリにnode-moduleをインストールできます。 ここでインストールしたものは、デプロイ時にlambdaの環境下にいきます。 コード ここでは、lambdaのコードを作ります。 ※データベースは、あらかじめ作成していてください let mysql = require('mysql'); exports.handler = async(event, context, callback) => { let connection; connection = mysql.createConnection({ host: process.env.databaseEndpoint, user: process.env.user, password: process.env.password, database: process.env.database }); try { const data = await new Promise((resolve, reject) => { connection.connect((err) => { if (err) { console.log('error connecting: ' + err.stack); return; } console.log('success'); }); connection.query('select * from sample', function(err, rows) { if (err) { throw err; } resolve(rows); }); }); const response = { statusCode: 200, headers: { "x-custom-header": "My Header Value", }, body: JSON.stringify(data), }; connection.end(); callback(null, response) } catch (err) { callback(null, { statusCode: 400, body: err.message }) } }; 上記のコードをデプロイするとWEBAPIとしてデータベースを見ることができます。 ネットワーク はい、嘘つきました。 実は、説明した通りだとラムダにネットワークの設定がされていないはずなので、データベースに接続できないです。 以下の手順を踏んでください 関数にVPC（データベースと同一）を設定する ラムダ関数に付与されているロールにAWSLambdaVPCAccessExecutionRoleを付与 ラムダにセキュリティグループの設定を行なってください mysqlとのインバウンドルールを追加します（かってに追加される気がする） あとがき 自分の経験を元に書いているので、もしかしたら何か抜けている可能性があります。 nodejsには、サーバレスのフレームワークがあったのでlambdaを作成するのであれば、それを利用する方が、簡単かもしれないです。