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

CloudFormationをゼロから勉強する。（その６：Transformによるインクルード）

# はじめに
今回はまだ試していなかった`Transform`のうち、他テンプレートのインクルード機能を使ってみようと思います。

– 【前】[CloudFormationをゼロから勉強する。（その５：マッピングと条件式）](https://qiita.com/sakai00kou/items/f562f02fe0fc8719ef65)

# Transformセクションについて
`CloudFormation`から`Lambda`関数を呼び出す場合や、他のテンプレートをインクルードする場合に使用します。

今回使う他テンプレートのインクルードは、テンプレート内のどこでも呼び出すことができ、呼び出す位置によって若干構文が変わってきます。

ただ、インクルードで使う場合はトップレベルで使う場合でも`Fn::Transform`だけ覚えておけばよいと思います。（理由は後述）

“`yaml:Transformサンプル（トップレベルで使用する場合の構文）
Transform:
Name: ‘AWS::Include’
Parameters:
Location: ‘s3://

no space left on device, writeがCloud9で出たので解決してみた

AWSを使っていて、gemfileを保存しようとしたら、以下のエラーが出た。
“`
no space left on device, write
“`
というエラーが出た。
直訳すると「このデバイスの要領はもうありませんよ」って意味だ。

だが、実際のところ要領がないわけではなく、ファイルの数が多くて、それが足りなかった。

なので、それを解決した

解決方法は簡単。いらないファイルを消した。

“`
rm -r ディレクトリ名
“`
のコマンドを入力するだけ。

これで、エラーは消えてくれた。

goofysでS3をUbuntuにマウントする

### バージョン確認
“`
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION=”Ubuntu 18.04.5 LTS”
“`

## goofysのインストール
Golang環境を構築して，ソースから入れることもできるようではある．
しかし自分が再現しようとしたところ，[公式のREADME.md](https://github.com/kahing/goofys)の

“`
$ go get github.com/kahing/goofys
“`

のところで詰まった．
2020年4月くらいに更新が止まっているので，そのままバイナリを落としていれることにする．

pre-buildバイナリファイルを落として，

“`
$ mv path-to-pre-build-binary-of-goofys ~/.local/bin
$ chmod +x ~/.local/bin
$ goofys
Error: goofys

【SOA対策】CloudWatch

# CloudWatchとは？
AWSリソース、アプリケーション、オンプレミスのモニタリングを行ってくれるマネージドサービス

# 重要用語

## ◯CloudWatch メトリクス
各リソースから送られてくるデータポイント（一定期間で送られてくる数値情報）のまとまりを`CloudWatch Metrics`と呼ぶ。

####□メトリクス種類
**標準メトリクス**
CPU使用率、ネットワーク使用率など

**カスタムメトリクス**
ディスク使用率、メモリ使用率など

※EC2モニタリング例
####□メトリクスの保存期間
| データポイント期間　|　保存期間 |
|:———–|:————|
| 60 秒未満（高分解能カスタムメトリクス） | 3 時間 |
| 60 秒（詳細モニタリング） | 15 日間 |
| 300 秒（標準） | 63 日間 |
| 3600 秒 | 455 日 (15 か月)|

####□Dimensions
メトリクスを特定するためのラベル、データ

非コンテナ環境のオンプレからFargateへのAPI移行時に発生したログ問題

この記事では、オンプレの非コンテナ環境で動くAPIをコンテナ環境(AWS Fargate)に移した時にやったこと、学んだことをログ周りに絞って書きます。

この記事から分かること

– コンテナ環境と非コンテナ環境でログをはじめとするデータの取り扱い方の違い
– Fargateで動作するコンテナからのログをFireLens, fluent-bitで取得する設定

環境はNginx＋Flask＋uWSGIで、uWSGI・fluent-bit・Nginxのコンテナをサイドカー構成でFargateで動かしています。

## コンテナのステートレス性を担保しよう
非コンテナ環境とコンテナ環境では多くの面で、勝手がかなり異なります。

コンテナ開発では、**コンテナのステートレス性** `コンテナは何らかの形の永続データ(状態)を内部に保持しないという性質` を常に担保しなければなりません。
これを担保してあげることで、データを損失する心配がなくなり頻繁にいつでもデプロイを行うことができるようになります。

これはコンテナの大きな利点の一つなので、是非担保したいところ。

このステートレス性を担

Nginxを例に、fluent-bitを使ってFireLensで集めた複数コンテナのログを加工・データストアに送信する

AWS FireLensをfluent-bitで組み合わせてログを取得・整形した時の知見を覚え書きの形でまとめます。

今回は、Nginx、uWSGIの二つのコンテナから取得するログをいい感じにAthenaで見れるようにすることが目標。

前提として、Fargate上で、サイドカー構成でNginxのコンテナとfluent-bitのコンテナを一つのTask内で動かすものとします。

いい感じとは、

– Nginxのアクセスログの内容がkey-value形式のjsonで表示できる
– ヘルスチェックのログなどいらないやつはS3にまで送られずにfluent-bit側で弾かれている
– エラーログはすぐに見たいのでS3だけでなくdatadog/cloudwatchにも送る

こんな感じのを目指す。
この記事ではNginxだけについて書きます。後は同じようなやり方で簡単に追加できると思うので。

##fluent-bitに関する必要知識
![fluent-bit公式サイトの図](https://gblobscdn.gitbook.com/assets%2F-LKKSx-3LBTCtaHbg0

Java Lambda の入出力型を試してみた〜Stream 編〜

Java Lambda の入出力の型には、いろんなパターンが使えます。

* Map 方式
* POJO 方式
* InputStream/OutputStream 方式

公式ドキュメントでは [ここ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html#java-handler-types) に書かれています。

[POJO 編](https://qiita.com/kazfuku/items/095b4fb9c37638f57457) では、POJO クラスを使用して JSON を扱う方法を紹介しました。

最後に、InputStream/OutputStream を使った Stream 編です。

前回の POJO 編に手を加えて、Jackson を使って自前で Parse、Generate するコードになります。

“`Java
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.servic

AWS DataPipelineに関して

## AWS Data Pipelineとは
AWS DataPipelineとはデータの移動や変換を自動化できるウェブサービスになります。DataPipelineは保存場所にあるデータに定期的にアクセスし、必要なスケールのリソースを使用して変換と処理を行っていきます。

## 実際に触ってみる。
それではさっそく触っていきたいと思います。

### ロールの作成
まずは二つのロールを作成します。IAMのロールのところからロールの作成を選択し作成します。

### Dyna

2時間でQiitaとはてブのトレンドをLINEに通知するプログラムを書いてAWSにデプロイした話

# はじめに

出社して、いつものトレンドチェックの日課をしていると、
以下の記事が目に留まりました。

[GitHubActionsでQiitaとSlackを繋いで、エンジニアにとっての良い習慣をつくる。](https://qiita.com/UhRhythm/items/219ee6653f25b63fc6cc)

そういえば自分以外のエンジニアがトレンドチェックしているの見かけたことないぞ?

というわけで、毎日チェックしてもらいたい [Qiita トレンド](https://qiita.com/) と [はてなブックマークIT トレンド](https://b.hatena.ne.jp/hotentry/it) を毎朝LINEに通知するシステムを作りました。

LINEアカウントを追加した人に、こんな感じの通知が届きます

# LI

Java Lambda の入出力型を試してみた〜POJO 編〜

Java Lambda の入出力の型には、いろんなパターンが使えます。

* Map 方式
* POJO 方式
* InputStream/OutputStream 方式

公式ドキュメントでは [ここ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html#java-handler-types) に書かれています。

[Map 編](https://qiita.com/kazfuku/items/6b2e9131eb5e6e175922) では、Map 型を使用して JSON を扱う方法を紹介しました。

Map 方式のコードをみてみると、Object 型から String/Integer/Long 型などへのキャストが多数現れます。

“`Java
public class MapFunction implements RequestHandler, Map> {
@Override
public Map

AWS CLI でGlobalAccelerator作成

# 公式ドキュメント

https://docs.aws.amazon.com/ja_jp/cli/latest/reference/globalaccelerator/index.html

https://docs.aws.amazon.com/ja_jp/global-accelerator/latest/dg/what-is-global-accelerator.html

# 前提条件

## AWS CLIバージョン

以下のバージョンで動作確認済
* AWS CLI 1.18.127

“`ruby:コマンド
aws –version
“`
“`ruby:結果
aws-cli/1.18.127 Python/3.6.12 Linux/4.14.193-113.317.amzn1.x86_64 botocore/1.17.50
“`

## ALB

既に作成済であること

# AWS CLI

## アクセラレータの作成

“`ruby:コマンド
# GA_NAME={アクセラレータ名}
# aws globalaccelerator create-acc

[AWS]各サービス概要

#VPC(Amazon Virtual Private Cloud)
利用者ごとにプライベートなネットワークをAWS内に作成出来る。
ネットワーク空間は可能な限り大きなサイズ(/16)で作成する。

– サブネット
– インターネットと通じているパブリックサブネットと、外との繋がりが無いプライベートサブネットに分けられ、同一の役割を持ったサブネットを、複数のAZに作るのが推奨されている。

– ルートテーブル
– VPC内部の通信や、インターネット・オンプレミス(※1)ネットワーク基盤など外部への通信を実装する。
– サブネットに1つずつ設定する。

– セキュリティグループ
– インスタンス単位の通信制御をするもので、インバウンド(外部からVPCへ)、アウトバウンド(VPCから外部へ)の両方からの制御が可能。

– ネットワークACL(アクセスコントロールリスト)
– サブネットごとの通信制御をする。

– ゲートウェイ
– VPCの内外部との通信をやり取りする出入り口のこと。主にインターネットゲートウェイ、仮想プライベートゲートウェイ、NATゲートウェイが

ACMで証明書を発行し、好きなドメインでcloudfrontを利用する

cloudfront.net以外のドメインでwebページを配信したのでやり方をまとめておきます
cloudfrontでページの配信はできたけどドメインを変えたいという人の参考になればと思います

## 目的
自分が取得したドメインを用いてコンテンツを配信する

### やること
– ACM(Amazon Certificate Manager)で証明書を発行する
– cloudfrontのCNAMEを設定する
– Route53でDNS設定をする

### 前提
– ドメインを取得済
– cloudfrontでコンテンツを配信済み

### ACMとは
AWS 管理のリソース(cloudfront, ELB)に対して SSL/TLS 認証のプロビジョニングを行うことができるサービスです
AWS限定ですが、証明書の発行が無料かつ簡単にできるということですね
使わない手はないです

## やり方

### ACM

リージョンをバージニアにしてからACMにアクセスします
(cloudfrontではバージニアしかACMを利用できません)
証明書のプロビジョニング欄の「今すぐ始める」をクリック

Java Lambda の入出力型を試してみた〜Map 編〜

Java Lambda の入出力の型には、いろんなパターンが使えます。

* Map 方式
* POJO 方式
* InputStream/OutputStream 方式

公式ドキュメントでは [ここ](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html#java-handler-types) に書かれています。

まずは、Map 方式から。

Lambda 関数に渡す入力 JSON はこれです。

“`Json
{
“name”: “orange juice”,
“price”: 1000,
“releaseDate”: 1601606387939,
“rate”: 4.5,
“rawMaterial”: [“orange”, “fragrance”],
“size”: {
“height”: 10,
“width”: 20,
“depth”: 30
}
}
“`

以下のコードでは、この入

AWS EC2にCentOS7 + Nginx + pm2 + Nuxt.jsで開発環境を構築する

# AWS EC2にCentOS7 + Nginx + pm2 + Nuxt.jsで開発環境を構築する

## はじめに

スタートアップ企業では、バックエンドからフロントエンドまでやりますが、今回はなんと開発環境の構築作業です！

躓いたことが多かったのでメモとして残します。

## 開発環境

Cloud: AWS EC2（t2.micro）
OS: CentOS7
FW: Nuxt.js
PM: pm2
その他: node.js, npm

## セットアップ

“`bash
sudo yum update -y
sudo yum clean all

sudo yum install gcc-c++

sudo yum install nodejs npm
sudo npm install -g n

sudo n stable

sudo yum remove nodejs npm
“`

“`bash
sudo npm install -g nuxt
sudo npm install -g pm2
“`

#### プロジェクトの作成

“`bash
cd /v

Clud9でrails serverを実行した時に出る「Webpacker」に関するエラー奮闘記

Railチュートリアル第２章学習中にrails serverのエラーが出ました。

“`
Webpacker configuration file not found
“`

Webpackerをインストールできていないみたいです。
言われた通りやりながら、解決していこうと思います。

##Webpackerをインストールしてみる
そういえば、先ほどからwebpackerをインストールしやがれ的なことはずっと言われていたのですが、そのまま進めていました。

“`
$rails webpacker:install
“`
webpackerをインストールすることにしました。
すると、

“`
Yarn not installed. Please download and install Yarn from https://yarnpkg.com/lang/en/docs/install/
“`
が出現しました。
Yarnをインストールしなければならないようです。

なので、Yarnをインストールしにかかりました。

npmからインストールする

“`
$ npm insta

AWS CopilotでECS FargateにRailsをデプロイ

# Copilotとは？
Copilotは[Amazon ECS CLI](https://github.com/aws/amazon-ecs-cli)の後継に当たるもので、
ECSでのコンテナ実行をより簡単に行う為に開発された環境構築ツールです
Copilotで構築するAWSリソースはCloudFormationによって管理され、
AWS CDK(プログラムでCloudFormationテンプレートを管理するツール)と違ってコードを書く必要は殆どありません！

[GitHub – aws/copilot-cli](https://github.com/aws/copilot-cli)
[Wiki](https://github.com/aws/copilot-cli/wiki/Getting-Started)

# Copilotのインストールと事前準備
homebrewでインストールまたはcurlで直接インストールができます

“`
# homebrew
$ brew install aws/tap/copilot-cli

# curlで直接インストール
$ curl -Lo

[EC2]インスタンスタイプの基本

## 勉強前のイメージ

EC2のインスタンスは大体適当に使うんだったらt2.microとかsmallとか…
あとはCPUとメモリでえいやーで決めてた

## 調査

### EC2インスタンスのネーミングポリシー


**t3a.2xlarge** : インスタンスタイプ

– t : インスタンスファミリー
– 3 : インスタンス世代
– a : 追加機能
– 2xlarge : インスタンスサイズ

### インスタンスファミリー

特徴を持った、5つのカテゴリに分類される

– 汎用
– コンピューティング最適化
– ストレージ最適化
– メモリ最適化
– 高速コンピューティング

#### 主なインスタンスファミリーの表

| カテゴリ | ファミリー

AWS SAM CLI で複数のコンフィグを使い分ける

先日 AWS SAM CLI [v1.3.0 がリリース](https://github.com/aws/aws-sam-cli/releases/tag/v1.3.0)され、マルチコンフィグがサポートされました。
このアップデートにより、これまで面倒だった複数コンフィグの使い分けがとても楽になったので紹介してみます。

まず AWS SAM CLI の簡単なおさらいをしてから、アップデート前後でどう変わったかを見ていきます。

# AWS SAM と AWS SAM CLI

AWS SAM (Serverless Application Model) はサーバレスアプリケーション構築用のフレームワークです。
CloudFormation テンプレートを拡張する SAM 構文を使ってテンプレートを記述することで、簡単にアーキテクチャを定義できます。

例えば API Gateway と Lambda だけのシンプルなアプリケーションなら、たったこれだけの行数で書くことができます。

“`yaml
AWSTemplateFormatVersion: ‘2010-09-09’
Tran

【AWS】Athenaでelbログを絞り込んで取得する

# はじめに
「athenaでelbのログを確認してもらってもいいっすか」って唐突に投げられたので準備と自分の好みのクエリを備忘録的に残しておきます

正直公式ドキュメントがこれでもかっていうくらい読みやすいのでそっちを参考にするべきだと思う
https://docs.aws.amazon.com/ja_jp/athena/latest/ug/application-load-balancer-logs.html

# テーブルの作成
上記の本家様に書いてある通りCREATEクエリを流し込めばテーブルが作成できます
左側に`create table`があるからGUI上からも作成できるけど、設定を元にクエリが作成される＋カラムの設定とかRegexをどうせコピペするのでクエリを最初から流し込んだ方がスムーズかと。

GUIから設定したい人向けに一応メモ

– Data Format: Apache Web Logs
– Regex: `'([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0