AWS関連のことを調べてみた2020年09月13日

DynamoDBテーブルを少なくするためにテーブルを統合する設計方法

# はじめに
こんにちは！
最近仕事でDynamoDBの設計について議論をしているとき、「DynamoDBのテーブルは一つだけにすることがベストプラクティス」というのが少し盛り上がりました。スキーマレスなDynamoDBならではの議論で面白いですね。実は私が前職で開発をしていた時にこれに近いことを実践していて、なるべくDynamoDBのテーブルは少なくなるような設計を行っていました。

この記事はその手法を共有したいと思います。

# 本記事の対象読者
* DynamoDBを使ったことがある方
* ハッシュキー、レンジキー、LSI、GSIがどういうものか何となく理解できている方

# なぜDynamoDBのテーブルは少ないほうが良いのか？
ひと昔前は[AWSのDynamoDB開発者ガイド](https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-general-nosql-design.html)に
> DynamoDB アプリケーションではできるだけ少ないテーブルを維持する必要があります。設計

AWS EC2 EC2 Instance (Amazon Linux AMI)の作成

#はじめに
今回は、AWS EC2を使用して、無料でできる範囲のLinuxサーバーを建ててみようと思います。
無料でできる範囲で実施しようと思いましたが、私の場合AWSアカウントを持って1年以上経過しているため、無理なようです。
ですので、実施したことをメモとして残します。

#今回実施する内容
AWS EC2を使用して、Amazon Linux AMI2を使用したLinuxサーバーを建てます。

#参考
[Tutorial: Getting started with Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html?trk=em_a131L000005jw1jQAA&trkCampaign=pac_EC2_docs_GettingStarted_GlobalEM&sc_channel=em&sc_campaign=GLOBAL_PM_AB_ec2_201904_&sc_medium=em_78339&sc_outcome=PaaS_Di

Rails本番環境に自動デプロイしたらwe’re sorry, but something went wrong.

# 恐怖のwe’re sorry, but something went wrong.

個人アプリを開発したぞ！
そして、追加実装したから設定済みの自動デプロイで本番環境のアプリを更新！
さぁ、本番環境への反映をチェックと……。

**we’re sorry, but something went wrong.**

何…..だと….!　?´д` ;
本番環境でアプリが開かない！？　:(；ﾞﾟ’ωﾟ’):

そのエラーに見事にハマった。
という事で、エラー解決に至るまでの死闘を描く。

**herokuへデプロイした際の同じエラー解決記事は結構見つかったものの、意外にMySQLでの解決策は見つからなかった。**

今回はMySQLでの対処法だが、we’re sorry, but something went wrong.エラーの

ElasticBeanstalk(Amazon Linux2)+RDS(MariaDB)でDjangoアプリをデプロイ

#こんにちは
初めて記事を投稿します。
タイトルの方法でWebアプリのデプロイを行ったので，備忘録として残しておきます。
ElasticBeanstalkは長いので以後EBと書きます。

##環境

windows10(2004)
Python3.8
Django3.1.1

##この記事を残す意味

[公式ガイド](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/create-deploy-python-django.html “Elastic Beanstalk への Django アプリケーションのデプロイ”)の方法に従ってデプロイを進めていくのですが，この通りにやると本番環境ではいくつかの問題が生じます。

###問題点

– **データベースにSQLite3を用いることになる**
本番環境で用いるデータベースとしてSQLiteは適切ではありません。
テスト環境においても，ディレクトリごとデプロイする仕様上，sqliteファイルをignoreしない限り，デプロイするたびにローカルのデータに上書きされ，オン

AWS考试笔记（CLF-C01）

# 概要
CLF-C01 – AWS Certified Cloud Practitioner – Chinese Simplified (CHS)

学习： 1.edx上清掉了[AWS Developer Series](https://courses.edx.org/dashboard/programs/c5a7a2ac-f318-49da-bb72-ed2440347744/)的3个考试; 2.书看掉了《AWS認定クラウドプラクティショナー》
刷题： [examtopics](https://www.examtopics.com/exams/amazon/aws-certified-cloud-practitioner/)

# 常考概念
### Amazon Macie
– 一句话：梅西，管理隐私数据
– Which AWS service provides the ability to detect inadvertent data leaks of personally identifiable information (PII) and user credential d

『AWS初学者向けハンズオン』EC2インスタンスからRDSインスタンスに接続してみる編

#初めに
この記事はAWS初学者が書いているAWS初学者の方や未経験の方向けの記事になります。
内容や説明が間違っていた場合はコメントいただけるとありがたいです。
###投稿者のレベル
AWS CLF持ってるレベル
AWS実務経験無し
AWS使用経験(個人用+会社作成アカウント使用)：約2ヶ月
ちょっと触ったことがあるサービス：IAM、EC2、EIP、VPC、RDS、CloudWatch(もしかしたら他にも使ったような気がする．．．)
最近本格的にAWSの勉強を始めたインフラエンジニアです。
###前提知識＆条件
[『AWS初学者向けハンズオン』VPCとEC2を使ってWebサーバの構築編](https://qiita.com/Mattun_0226/items/13b995481838a9b0efe0)
こちらの記事を事前に読んでいただけると今回行うハンズオンがスムーズに進みます。
またEC2インスタンスをSSHできる状態を作成します。
#今回の目的
EC2でデータベースサーバを構築することも可能ですが、RDSを使用することでバックアップやデータベースのスケーリングをAWSに任せること

【AWS・Lambda】エラーハンドリングの基礎 ~ Design for Failure ~

# はじめに

Lambdaのエラーハンドリングについて、
『AWS Japan Summit Online 2020』のオンラインセッションで学んだ [ Design for Failure ] の考え方をまとめます。

Lambdaの実行中には様々なエラーが予想されます。
それらに適切に対応するためのデザインが必要です。

# Lambda関数でエラーを受け取ったら？

Lambda関数は、エラーを受け取ると基本的に複数のリトライを行います。
不要なリトライは、膨大なログデータを発生させたり、無限にリトライし続けることで膨大な料金になってしまうことも考えられます。

# エラーへの対処

エラーへの対処には、主に以下3つの方法が考えられます。

1. 不要なリトライの回避
2. エラー伝播の回避
3. データ整合性の確保

## 不要なリトライの回避

無駄なリトライはトラブルの元です。リトライ設計を適切に考える必要があります。

リトライ設計で考慮するポイントは以下の通りです。

– 誰がリトライを実施するのか
– どれくらいの期間・何回リトライするのか
– イベン

AWS SAMのtipsをひたすら書く

#はじめに
タイトルめっちゃ雑ですみません。
筆者は約半年に渡って、aws-samを使ったアプリケーションを作成しています。
たくさんトラブルや学びがあったので、それらをメモしてきたいと思います。

#トラブルとその解決

### 開発環境と本番環境を分けたい
パラメータの上書きを使うと良いです。
筆者の場合はこんな感じです。

“`
Parameters:
AppId:
Type: String
Environment:
Type: String
“`

### リソース数が200を超えてこれ以上デプロイ出来ない
クロススタック参照を使うと良いです。
CodePipelineの画面はこんな感じになっています。

### デプロイが遅い
色々試しましたが、どうしようもあり

ECS Fargateデプロイ用CodePipelineのtaskdef.jsonに変数を持たせる方法

# はじめに
CodePipelineによるCI/CDパイプラインは便利なんだけど、せっかくTerraformやCloudFormationであれこれ変数化して自動化しているにもかかわらず、ECS Fargateにデプロイするための taskdef.json と Appspec.yml で変数化できずにハマるケースがあって困る。今回は、これを解決する手段を考えた。

# 前提条件
初学者向けのパイプライン作成ハンズオンに出てくるアウトプットをごちゃごちゃいじるので、少なくとも、CodePipelineの基礎は抑えていないと厳しい。過去の記事では以下のあたりを読んでおくと分かりやすくなっているはずだ。
なお、この記事ではIaCはTerraformで書いている。

– [CloudFormationテンプレートを1からしっかり理解しながらECS on Fargateなアプリを自動構築する(前編)](https://qiita.com/neruneruo/items/06b073f3846803f415e5)
– [CloudFormationテンプレートを1からしっかり理解しながらECS

Railsの本番環境でなぜかセッションが保存できない問題を解決した経緯

#概要
railsで本番環境にプッシュしたアプリがある日セッションを使った機能の全てが動作しなくなるという絶望的な問題にぶち当たった。めちゃくちゃ苦戦したし記事も全然なかったのでその解決方法を記しておく。

最終的にこの記事から設定しなおして解決しました。

【Rails】ActionController::InvalidAuthenticityToken (ELB,EC2)

#環境
・EC2にデプロイ
・サーバー環境はWebサーバーにnginx、アプリケーションサーバーにPuma
・AWSのELBにACMのSSL証明書をアタッチしてSSL化↓

クライアント→ELB→nginx→puma

#セッションが保存されない原因
####まず、セッションが保存されない原因
RailsではCSRF（クロスサイトリクエストフォージェリー）という脆弱性からサイトを守るための対策として
protect_from_forgeryというメソッドでサイトを保護している
“`application.html.erb“`のheadタグ内に“`csrf_meta_tag“`という記述をしているが
ここで認証用のauthenticate_tokenを生

【AWS】から学ぶデータベース基礎 [ Purpose Build ] の考え方

# はじめに

私のような**令和プログラマー*1**にとって、圧倒的に不足しがちなのがDB・ネットワーク等のインフラ周りの知識・経験です。

（*1: 令和になってからプログラミングを知った人。初心者のこと。）

しかしながら、AWSやFirebase等のマネージドサービスを活用することで、これまでよりも簡単に、セキュリティ・可用性の高い堅牢なインフラ運用を体験することができるようになっています。

今回は『AWS Japan Summit Online 2020』のオンラインセッションで学んだ
データベース基礎 [ Purpose Build ] の考え方をまとめます。

# 様々なデータベース

私のような初心者にとって『データベース = リレーショナルデータベース』でした。

しかし現代には様々なデータベースが存在し、実際にAWSでは以下の種類のDBサービスを提供しています。

– Relational
– Key-Value
– Document
– In-Memory
– Graph
– Time-Series
– Ledger

要件に合わせた最適なD

LambdaとAmazon ConnectでRDS障害時のSlack通知と電話連絡を行う

# 概要
* RDSで障害が起きた時にSlackに通知すると同時に電話も掛けて欲しかったのでLambdaとConnectを使って実装しました。
* 単純に電話を掛けるだけではなく、複数人に電話をして１人目が対応可能だったら他の人には電話せずということも実現したかったのでそれも実装しました。
* 実際に実装してみて気になる細かい点（後述）はありますが、それは徐々に改善していこうと思っています。

# 処理の流れ
* RDSのイベントでトリガー
* SNSが受け取ってSlack通知用Lambda（Lambda1）と電話連絡用Lambda（Lambda2）を呼び出す
* Slack通知用LambdaはRDSイベントの内容（どのRDSでどんな障害なのか）をSlackに通知
* 電話連絡用LambdaはConnectを呼び出して電話を掛ける
* 誰が対応可能なのか判定も行ってSlackへ通知

![rds-event-flow.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3868

これまで書いてきた記事を整理した

記事の本数が50本を超えたので、これまで書いてきた記事をカテゴライズして整理した。
1つの記事が複数のカテゴリに入るので、同じ記事が2度登場したりするが、気にしないでいただきたい。

# AWSサービス系
## ECS
– [AWSのアカウント作った直後の状態からECS＋FargateでTomcatのDockerコンテナを起動する](https://qiita.com/neruneruo/items/82c9daf90d5782f150d2)
– [AWSでSpringBootベースのWebアプリを起動してみる(Docker on EC2編/ECS＋Fargate編)](https://qiita.com/neruneruo/items/ff6747a4129a5b52e6c6)
– [CloudFormationテンプレートを1からしっかり理解しながらECS on Fargateなアプリを自動構築する(前編)](https://qiita.com/neruneruo/items/06b073f3846803f415e5)
– [CloudFormationテンプレートを1からしっかり

AWSクラウドプラクティショナーに合格したのでやって良かったこと&本番トラブルを振り返ってみる

先日オンライン自宅受験でAWSクラウドプラクティショナーに合格しました。直前1週間はかなり焦って無我夢中で対策していたので、一旦落ち着いて振り返ってみたいと思います。
だらだらと書いていますが、受験を考えている方のご参考になれば幸いです。
ちなみに結果は895/1000で、合格ラインの700点と比べると比較的余裕がありました。

経歴

• AWSはEC2やVPC、S3などほんの少しだけ触っていました。業務での利用はなし。
• 基本情報技術者（FE）だけ取得済み
• 仕事の一環でクラウド全般やAWSの基礎講座を何回か受けていました。

勉強時間

30~40時間程度。試験のために本腰を入れたのは約1週間前からで、おそらく20時間くらい。
試験関係なく、AWSの勉強自体を始めていたのは2か月前くらいだったと思います。

やったこと（◎必須、〇やってよかった、△プラスアルファ）

◎ 公式の試験ガイドを確認する
◎ 公式のサンプル問題（10問）
◎ 各サービスの紹介ページをみて概要を確認する

AWS AmplifyでS3のBucket名を取得する [メモ]

## はじめに
基本は自分のための備忘録だが、誰かの参考になれば幸い。
なお、クイックハックです。正式なやり方ではないと思うのでご注意を。

## 動機
AWSのAmplifyを使ってモバイルアプリを作ることになったが、使いやすい半面、小回りがきかなそうで困ってる。

### すごいざっくりのAmplify概要
Amplifyは、CLIから簡単にバックエンドを構築できて、そのバックエンドへのアクセス方法をライブラリが隠蔽するので、開発者はその詳細を知らなくてもアクセス出来るというところがメリット。

また、Dev -> Prodの2Stageで開発するときに、アプリで使うバックエンドを下記のコマンドでDev用、Prod用に切り替えることが出来る。当然、開発者はバックエンドの詳細を知らなくてもよい。

“`
$ amplify env checkout
“`

### 困ってること
詳細が隠蔽されているので、バックエンドのリソース名が取れない（ようにみえる）。
例えば、バケット名を表示したいと思っても、のバケット名を取得する方法がない（ようにみえる）。

~~具体的に

AWS EC2 AmazonLinux2に導入したMailCatcherでLaravelのメールの受け取りを行う

# 目的

– AWS EC2 AmazonLinux2インスタンスに導入したMailCatcherにてLaravelから送られてきたメールを受け取る方法をまとめる

# 前提条件

– AWS EC2 AmazonLinux2インスタンスにLaravelの動作環境が構築されていること。

# 前提情報

– 下記の方法で構築したLaravel環境にMailCatcherを導入し作業を行う。
– [AWS EC2 AmazonLinux2だけでLaravelのアプリをデプロイする](https://qiita.com/miriwo/items/b39d1ac6289c54cc2cfd)

# 読後感

– AWSのインスタンス内に構築したLaravelアプリから送信されたメールを同じインスタンス内に導入されたMailCatcherで受け取ることができる。

# 概要

1. MailCatcherの導入
1. .envファイルの記載
1. 確認

# 詳細

1. MailCatcherの導入
1. 下記の方法でAWS EC2 AmazonLinux2にMailCatc

AWS日記18 (Step Functions)

# はじめに
今回は AWS Step Functions を試します。
画像を自動的に変換・サイズ変更するページを作成します。
[Lambda関数・SAMテンプレート]
(https://github.com/tanaka-takurou/serverless-application-step-functions-page-go)

# 準備
[AWS SAM の準備をします](https://qiita.com/tanaka_takurou/items/cae7c19fc3aaf0031abb)

[AWS SAMの資料]
[AWS Step Functions](https://aws.amazon.com/jp/step-functions/)
[Create a Step Functions State Machine Using AWS SAM](https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/tutorial-state-machine-using-sam.html)

# AWS SAM テンプレ

Amazon API GatewayでサクッとCORS対応する

# はじめに
Amazon API GatewayとS3の静的Webサイトホスティングを組み合わせると、サーバレスで何でもできるようになるのだけど、当然のことながらオリジンが変わってしまうので、CORSの設定が必要。
マネコンからは一発でCORSの設定を入れることができるものの、IaCと組み合わせてると、マネコンからの変更は色々と不都合があるので、ここはTerraform一撃でCORSの設定を入れられるようにしてしまおう。

CORSって何？という人は[クラメソ先生](https://dev.classmethod.jp/articles/about-cors/)に教えてもらおう！

# 簡単なリクエスト編(GETメソッド)
GETについては、レスポンスのheadersでCORSを許容することを示せば良い。

具体的には、“`Access-Control-Allow-Headers“`、“`Access-Control-Allow-Origin“`、“`Access-Control-Allow-Methods“`を返す。

以下はPython＋API Gatewayの統合レ

AWSを使ってアプリケーションを公開する手順(6)Nginxを導入する

#はじめに
AWSを使ってアプリケーションを公開する手順を記載していく。
この記事ではWebサーバであるNginxを導入する。

#Nginxをインストールする
##Nginxとは
NginxとはWebサーバの一種である。
ユーザのリクエストに対して静的なコンテンツの取り出し処理を行い、動的なコンテンツの生成をアプリケーションサーバに依頼する。

##「.ssh」ディレクトリに移動する
以下のコマンドを実行し、「.ssh」ディレクトリに移動する。

“`
cd ~/.ssh/
“`

##ssh接続
以下のコマンドを実行し、EC2インスタンスにsshでアクセスする。
(ダウンロードしたpemファイル名が「xxx.pem」、ElasticIPが123.456.789の場合)

“`
ssh -i xxx.pem ec2-user@123.456.789
“`

##Nginxのインストール
以下のコマンドを実行し、Nginxをインストールする。

“`
sudo yum -y install nginx
“`

#Nginxの設定ファイルを編集する
以下のコマンドを実行しvi

《コロナに負けず!!》29歳で営業職からジョブチェンジ。未経験で受託開発企業から内定を頂けました。

## はじめに
昨年「エンジニアになるぞ！」と決意をし、
今年の3月に前職を退職(最終出社)、
3月下旬からプログラミングスクールに通いました。

現在、29歳(今年で30歳！)です。
新卒からずっと営業職で、プログラミングは未経験。

そんな自分でも、webエンジニアのスタートラインに
立つ事が出来ました。

自分なりに戦略を立てて行った就活でもありましたので、
就職活動中の方の参考にして頂ければ幸いです。

## 目次
・工夫して就活を行おうとした背景
・就活の結果
・学習開始〜内定までの流れ
・今回の転職活動でのポイント
・ポートフォリオについてのポイント
・学習方法について(おまけ)
・最後に

## 工夫して就活を行おうとした背景
(興味ない方は読み飛ばして下さい！笑)

スクールに入った時点の私は転職に関しての認識が甘く、

「高い金額のスクールで基礎をしっかり学べば、転職はできるはず！」
「スクールからも紹介があるし！」
などと、このくらいの認識でした。

ですが、この認識は間違いです！！！

少なくとも、20代前半の若い方でない限りは
エージェントからの紹介案件はごく