
開発用にAWS EC2でMacインスタンスを借りました。
セットアップの際にXCodeのインストールで躓いたので解消方法をメモしておきます。


Amazon EC2 Mac Instanceの利用方法は[こちら](https://qiita.com/hirosys-biz/items/52c971f6076efab3aeb3)の記事を参考にしました。


XCodeをインストールしようとするとこのように十分な空き容量がない旨のメッセージが出てインストールができない。

![xcode](/images/posts/280/289/xcode.png)

Mac App Storeからだと必要以上に容量を求められるらしいので、[developer.apple.com](https://developer.apple.com/download/more/)から直接インストーラーをダウンロードしてみましたが、こちらもダメでした。

![xip](/images/posts/280/289/xip.png)

インスタンスを作成する際に200GBのボリュームを指定しています。
しかし、ディスクの空き容量を確認すると`/dev/disk2s4s1   60Gi`と小さく、割り当てたはずのボリュームが認識していないようです。

```bash
 % df -h
Filesystem       Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk2s4s1   60Gi   14Gi   22Gi    40%  568975  626528225    0%   /
devfs           191Ki  191Ki    0Bi   100%     662          0  100%   /dev
/dev/disk2s6     60Gi   20Ki   22Gi     1%       0  627097200    0%   /System/Volumes/VM
/dev/disk2s2     60Gi  278Mi   22Gi     2%     725  627096475    0%   /System/Volumes/Preboot
/dev/disk2s5     60Gi  244Ki   22Gi     1%      14  627097186    0%   /System/Volumes/Update
/dev/disk2s1     60Gi   23Gi   22Gi    52%  475239  626621961    0%   /System/Volumes/Data
map auto_home     0Bi    0Bi    0Bi   100%       0          0  100%   /System/Volumes/Data/home
/dev/disk3s2    240Mi  240Mi    0Bi   100%     356 4294966923    0%   /Volumes/Google Chrome
```

## Resize the APFS drive to use all available storage

- [Start development of business apps on Amazon EC2 with macOS AMI](https://blogs.sap.com/2021/01/28/start-development-of-business-apps-on-amazon-ec2-with-macos-ami/)

こちらの記事の手順でAPFS(Apple File System)の割り当てを変更して全てのボリュームを利用できるようにしていきます。
Resize the APFS drive to use all available storageの項からの手順です。

以下の４つのステップで進めます。

1. 使っているAPFSコンテナを特定する
2. （オプション）インスタンスのスナップショットを作成する
3. ディスクの修復をする
4. APFSコンテナのリサイズをする

### 1. 使っているAPFSコンテナを特定する

```bash
diskutil list physical external
```
このコマンドでディスクの中でも物理の外付けディスクを確認できる。

```bash
% diskutil list physical external
/dev/disk0 (external, physical):
   #:       TYPE NAME             SIZE     IDENTIFIER
   0: GUID_partition_scheme      *214.7 GB   disk0
   1:        EFI ⁨EFI⁩              209.7 MB   disk0s1
   2: Apple_APFS ⁨Container disk2⁩   64.2 GB   disk0s2 <- これ
```

`disk0s2`がAPFSです。`64.2 GB`しか認識していないことがわかる。

`/dev/disk0`をリサイズします。

### 2. （オプション）インスタンスのスナップショットを作成する

ディスクシステムの設定を変える前にスナップショットやAMIを作成することをお勧めします。

- AMI https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/tkv-create-ami-from-instance.html
- スナップショット https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html#ebs-create-snapshot


![snapshot](/images/posts/280/289/snapshot.png)

### 3. ディスクの修復をする
```bash
% diskutil repairDisk <target disk>

# ex,
% sudo diskutil repairDisk /dev/disk0        
```

リサイズする前に`diskutil repairDisk <target disk>`コマンドを実行してパーティションを修復します。
```bash
% sudo diskutil repairDisk /dev/disk0        
Repairing the partition map might erase disk0s1, proceed? (y/N) y
Started partition map repair on disk0
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Did grow entire partition map
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
The partition map appears to be OK
Finished partition map repair on disk0
```

### 4. APFSコンテナのリサイズをする

すべての準備が整ったので、APFSコンテナのサイズ変更プロセスを開始できます。
このコマンドを入力するだけです。
```
% sudo diskutil apfs resizeContainer disk0s2 0
```

このコマンドで、システムは使用可能なすべてのストレージを使えるようにします。
`0`の代わりに特定の値を設定して利用するサイズを指定できます。


```bash
% sudo diskutil apfs resizeContainer disk0s2 0
Started APFS operation
Aligning grow delta to 150,323,855,360 bytes and targeting a new physical store size of 214,538,608,640 bytes
Determined the maximum size for the targeted physical store of this APFS Container to be 214,537,580,544 bytes
Resizing APFS Container designated by APFS Container Reference disk2
The specific APFS Physical Store being resized is disk0s2
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD - Data was formatted by newfs_apfs (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by diskmanagementd (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by diskmanagementd (945.275.7) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Macintosh HD was formatted by storagekitd (1677.81.1) and last modified by apfs_kext (1677.81.1)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 1 (com.apple.os.update-35C699ADD439C653A3B09EBD8A30FBD366881244EB7C82207A2E135362FCCB7F)
Checking the extent ref tree
Checking the fsroot tree
Checking the file extent tree
Checking volume
Checking the APFS volume superblock
The volume Update was formatted by com.apple.Mobile (1677.81.1) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by com.apple.Mobile (1677.81.1) and last modified by apfs_kext (1677.60.23)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Growing APFS Physical Store disk0s2 from 64,214,753,280 to 214,538,608,640 bytes
Modifying partition map
Growing APFS data structures
Finished APFS operation
```

### サイズの確認

サイズが変更できたか確認します。

```bash
% diskutil list physical external
/dev/disk0 (external, physical):
   #:                  TYPE NAME               SIZE       IDENTIFIER
   0: GUID_partition_scheme                   *214.7 GB   disk0
   1:                   EFI ⁨EFI⁩                209.7 MB   disk0s1
   2:            Apple_APFS ⁨Container disk2⁩    214.5 GB   disk0s2
```

APFSコンテナが64.2 GBから214.5GBに変わっていました。

```bash
% df -h
Filesystem       Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk2s4s1  200Gi   14Gi   68Gi    18%  568975 2094534625    0%   /
devfs           195Ki  195Ki    0Bi   100%     674          0  100%   /dev
/dev/disk2s6    200Gi   48Gi   68Gi    42%      48 2095103552    0%   /System/Volumes/VM
/dev/disk2s2    200Gi  278Mi   68Gi     1%     725 2095102875    0%   /System/Volumes/Preboot
/dev/disk2s5    200Gi  244Ki   68Gi     1%      14 2095103586    0%   /System/Volumes/Update
/dev/disk2s1    200Gi   69Gi   68Gi    51% 1766297 2093337303    0%   /System/Volumes/Data
map auto_home     0Bi    0Bi    0Bi   100%       0          0  100%   /System/Volumes/Data/home
/dev/disk3s2    240Mi  240Mi    0Bi   100%     356 4294966923    0%   /Volumes/Google Chrome
/dev/disk0s1    197Mi  5.5Ki  197Mi     1%       0          0  100%   /private/var/tmp/MPOOL4FS
/dev/disk4s1    130Mi  110Mi   21Mi    85%     693 4294966586    0%   /Volumes/Visual Studio for Mac Installer
```
dfコマンドでもSizeが変わっていることが確認できます。
（後日とったのでUsedなど細かい数字は一致しません）

## XCodeのインストール

ストレージが増えたことでMac App StoreからXCodeがインストール出来ました。

以上。

AWS EC2のMacインスタンスで容量が足らずにXCodeがインストールできないときの解決方法


CentOS7のEBSのボリュームを小さくするのがかなり大変だったので、備忘録として残します。
ほぼ[EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)の通り進めています。
自分の知らなかった部分を補足しました。

## EBSは簡単に大きくできるが小さくするのは大変

Elastic Block Store(EBS)はEC2の仮想的な記憶領域で、柔軟に容量を増やしたりスナップショットを取ってバックアップや複製が簡単に出来ます。
ただし、一度大きくしたEBSを小さくすることはできません。
これから新しく作成してAMIに登録する場合は、小さめのボリュームにしておくことをお勧めします。

![ebs](/images/posts/240/243/ebs.png)

では、どうやって小さくするかというと、新しく小さいボリュームのEBSを用意してそこにコピーすることでEBSのボリュームを小さくできます。
EC2のルートデバイスとして認識させる必要があるため、パーティションの設定も正しく行います。

## 標準ファイルシステム ext4とxfs

ボリュームのコピーは標準ファイルシステムによってコマンドが異なるので注意してください。

CentOS7のファイルシステムはxfsで、この記事はそのコピーの方法で進めます。
同じくxfsのOSはAmazon Linux2、Red Hat Enterprise Linux 7など。
対してext4のOSはCentOS6、Amazon Linux、そしてUbuntuです。

ext4のボリューム縮小は[参考1: Amazon EC2ルートボリュームのサイズを縮小してみた](https://techblog.forgevision.com/entry/2018/09/10/172633)を参照されると分かり安いと思います。

xfsはほぼ[参考2: EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)の通り進めました。


## CentOS7のEBSのボリュームを小さくする
AMIで利用しやすいように、200GBのボリュームから20GBへ小さくしました。
OS+ミドルウェアで４GB、swap領域で数GB使っていたので最小を20GBとしています。

参考1に倣って言葉の定義をします。
- 新EBSボリューム：新規起動したEC2インスタンスのEBSルートボリューム
- 旧EBSボリューム：縮小対象EC2インスタンスのEBSルートボリューム


手順は次の通り。
1. 任意の作業用EC2インスタンスに新EBSボリュームと旧EBSボリュームをアタッチする
2. 新EBSボリュームのパーティションを設定する
3. 新旧EBSボリュームをマウントする
4. 新EBSボリュームを旧EBSボリュームと同期する
5. ボリュームを取り外す
6. EC2にアタッチして起動する

### 1. 任意の作業用EC2インスタンスに新EBSボリュームと旧EBSボリュームをアタッチする
EBSをコピーするために新旧EBSボリュームを別の作業用EC2にアタッチします。
作業用EC2はOSがAmazon Linux2です。
インスタンスタイプはt3.microで十分でした。

アタッチ後のブロックデバイス一覧。
```sh
# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk 
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  200G  0 disk <-旧EBSボリューム
└─xvdf1 202:81   0  200G  0 part
xvdg    202:96   0   20G  0 disk <-新EBSボリューム
```
`xvdf`が旧EBSボリュームで`xvdg`が新EBSボリュームです。

### 2. 新EBSボリュームのパーティションを設定する

新EBSボリュームにパーティション`xvdg1`を作ります。
（パーティション内状態でコピーしたら、EC2がルートデバイスとして認識してくれなかった）


```sh
# fdisk /dev/xvdg

fdisk (util-linux 2.30.2) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。

古い xfs 署名は write (書き込み)コマンドを実行すると消えてしまいます。

デバイスには認識可能なパーティション情報が含まれていません。
新しい DOS ディスクラベルを作成しました。識別子は 0x3800409a です。

コマンド (m でヘルプ): n
パーティションタイプ
   p   基本パーティション (0 プライマリ, 0 拡張, 4 空き)
   e   拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (1-4, 既定値 1): 1
最初のセクタ (2048-41943039, 既定値 2048):
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (2048-41943039, 既定値 41943039):

新しいパーティション 1 をタイプ Linux、サイズ 20 GiB で作成しました。

コマンド (m でヘルプ): a
パーティション 1 を選択
パーティション 1 の起動フラグを有効にしました。

コマンド (m でヘルプ): p
ディスク /dev/xvdg: 20 GiB, 21474836480 バイト, 41943040 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3800409a

デバイス   起動 開始位置 最後から   セクタ サイズ Id タイプ
/dev/xvdg1 *        2048 41943039 41940992    20G 83 Linux

コマンド (m でヘルプ): w
パーティション情報が変更されました。
```
設定が日本語になっていた。
`n -> p -> 1 -> a -> w`でディスクサイズと同じ大きさのパーティション`xvdg1`ができる。
`m`でヘルプが見れます。


１度目はパーティション情報の書き込みで失敗している。
下はその時のログ。
再起動してもう一度実行したら成功しました。
```sh
コマンド (m でヘルプ): w
パーティション情報が変更されました。
ioctl() を呼び出してパーティション情報を再読み込みします。
パーティション情報の再読み込みに失敗しました。: Device or resource busy

カーネルは古い情報を使用しています。新しい情報を利用するには、システムを再起動するか、もしくは partprobe(8) または kpartx(8) を実行してください。
```

縮小前後(xvdf/xvdg)で同様の設定になっている事を確認します。
```sh
# fdisk -l
ディスク /dev/xvda: 8 GiB, 8589934592 バイト, 16777216 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 83181C97-6D5E-43C9-9EDE-E2F50EAD5338

デバイス     開始位置 最後から   セクタ サイズ タイプ
/dev/xvda1       4096 16777182 16773087     8G Linux ファイルシステム
/dev/xvda128     2048     4095     2048     1M BIOS 起動

パーティション情報の項目がディスクの順序と一致しません。


ディスク /dev/xvdg: 20 GiB, 21474836480 バイト, 41943040 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x3800409a

デバイス   起動 開始位置 最後から   セクタ サイズ Id タイプ
/dev/xvdg1 *        2048 41943039 41940992    20G 83 Linux


ディスク /dev/xvdf: 200 GiB, 214748364800 バイト, 419430400 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x000aec37

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/xvdf1 *        2048 419430366 419428319   200G 83 Linux
```

### 3. 新旧EBSボリュームをマウントする
```sh
# mkdir -p /mnt/old /mnt/new/boot
# mount -t xfs /dev/xvdf1 /mnt/old
# mount -t xfs /dev/xvdg1 /mnt/new

# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk 
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  200G  0 disk
└─xvdf1 202:81   0  200G  0 part /mnt/old <-旧EBSボリューム
xvdg    202:96   0   20G  0 disk 
└─xvdg1 202:97   0   20G  0 part /mnt/new <-新EBSボリューム
```

### 4. 新EBSボリュームを旧EBSボリュームと同期する

この辺りから自分の言葉で表せない、申し訳ないが参考の手順とその時の出力をのせる。

xfs を扱うためのパッケージをインストールしておきます。
- [xfsdump](https://www.atmarkit.co.jp/ait/articles/1804/26/news045.html): XFSファイルシステムをバックアップするために、指定した場所にコピーするコマンド
- [xfsprogs](https://www.atmarkit.co.jp/ait/articles/1804/27/news037.html): xfsdumpのバックアップからファイルを復元するコマンド
インストールコマンド: `yum install xfsprogs xfsdump`

容量により時間が掛かるのでバックグラウンド実行しておきます。
```sh
# cd /mnt/old/
( LANG=C date; nohup xfsdump -J - /mnt/old \
  | xfsrestore -J -p 60 - /mnt/new ; date \
) > /tmp/disk-sync.log 2>&1  < /dev/null &

# ログ
# tail -f /tmp/disk-sync.log
xfsrestore: media label: ""
xfsrestore: file system id: 0f790447-ebef-4ca0-b229-d0aa1985d57f
xfsrestore: session id: 606c299e-31bf-4de9-9bff-36538c642a89
xfsrestore: media id: dafc54f9-af51-4412-88d3-32cfe9298f5d
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsdump: dumping non-directory files
xfsrestore: 21868 directories and 127203 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: status at 10:06:38: 42584/98461 files restored, 47.9% complete, 60 seconds elapsed
xfsdump: ending media file
xfsdump: media file size 4563930720 bytes
xfsdump: dump size (non-dir files) : 4521594712 bytes
xfsdump: dump complete: 111 seconds elapsed
xfsdump: Dump Status: SUCCESS
xfsrestore: restore complete: 112 seconds elapsed
xfsrestore: Restore Status: SUCCESS
2020年  4月  9日 木曜日 10:07:30 UTC


^C[1]+  終了                  ( LANG=C date; nohup xfsdump -J - /mnt/old | xfsrestore -J -p 60 - /mnt/new; date ) > /tmp/disk-sync.log 2>&1 < /dev/null
```

5) grubインストール
chroot
OS起動時に作成されるディレクトリ群をマウントした後、 /mnt/new/ に対して chroot します。 (chroot した事を確認するためにログファイルコピーを行っていますが、必須ではありません。)

```sh
[root@ip-172-31-19-210 old]# cp -ip /tmp/disk-sync.log /mnt/new/var/log/
[root@ip-172-31-19-210 old]# gzip /mnt/new/var/log/disk-sync.log
[root@ip-172-31-19-210 old]# ls -l /mnt/new/var/log/disk-sync.log*
-rw-r--r-- 1 root root 820  4月  9 10:07 /mnt/new/var/log/disk-sync.log.gz
[root@ip-172-31-19-210 old]# mount -t proc /proc /mnt/new/proc
[root@ip-172-31-19-210 old]# mount -t sysfs /sys /mnt/new/sys
[root@ip-172-31-19-210 old]# mount --bind /dev /mnt/new/dev
[root@ip-172-31-19-210 old]# chroot /mnt/new/
[root@ip-172-31-19-210 /]# ls -l /var/log/disk-sync.log.gz
-rw-r--r-- 1 root root 820  4月  9 19:07 /var/log/disk-sync.log.gz
[root@ip-172-31-19-210 /]# 
```

grub xfs

```sh
[root@ip-172-31-19-210 /]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1062.9.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1062.9.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.14.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.14.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.4.2.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-123.8.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-123.8.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f9afeb75a5a382dce8269887a67fbf58
Found initrd image: /boot/initramfs-0-rescue-f9afeb75a5a382dce8269887a67fbf58.img
done
[root@ip-172-31-19-210 /]# grub2-install /dev/xvdg
Installing for i386-pc platform.
Installation finished. No error reported.
```

6) fstab/grub.conf 書き換え
fstab 、grub.conf に UUID 指定がある場合は、書き換えを行います。 (CentOS6 には grub-mkconfig が無いようなので grub.conf は直接書き換えています。)
xfs
UUID指定部分を書き換えます。 CentOS7 では grub2 が導入済みのようなので /etc/grub/ ではなく、 /etc/grub2/ が使用されます。

```sh
[root@ip-172-31-19-210 /]# blkid | grep xvdg
/dev/xvdg1: UUID="80ef9b35-2d25-430c-a753-5f6bbc2955e5" TYPE="xfs"
[root@ip-172-31-19-210 /]#  cp -ip /etc/fstab /etc/fstab.org
[root@ip-172-31-19-210 /]# vi /etc/fstab
# diff /etc/fstab.org /etc/fstab
9c9
< UUID=0f790447-ebef-4ca0-b229-d0aa1985d57f /                       xfs     defaults        1 1
---
> UUID=80ef9b35-2d25-430c-a753-5f6bbc2955e5 /                       xfs     defaults        1 1

# chrootを抜ける
[root@ip-172-31-19-210 /]# exit
exit
```

### 5. ボリュームを取り外す
アンマウント

`proc`、`sys`、`dev`もアンマウントしておく。
```sh
[root@ip-172-31-19-210 old]# cd /
[root@ip-172-31-19-210 /]# umount /mnt/old/
[root@ip-172-31-19-210 /]# umount /mnt/new/proc /mnt/new/sys /mnt/new/dev
[root@ip-172-31-19-210 /]# umount /mnt/new/
[root@ip-172-31-19-210 /]# mount -l | grep "old\|new"
```
ディスク内容の移行が完了したら、 作業用インスタンスから Volume をデタッチして後続作業を行います。

インスタンスを停止して、デタッチ。

## 6. EC2にアタッチして起動する

EC2の `/dev/sda1` にアタッチする。

※ デバイス名が`/dev/sda`だとエラーで`/dev/sdf`だとルートデバイスとして認識しなかった。

```sh
# sshでEC2に接続

$ df -h
df: `/s3': 通信端点が接続されていません
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         472M     0  472M    0% /dev
tmpfs            495M     0  495M    0% /dev/shm
tmpfs            495M   13M  482M    3% /run
tmpfs            495M     0  495M    0% /sys/fs/cgroup
/dev/xvda1        20G  4.5G   16G   23% /
tmpfs             99M     0   99M    0% /run/user/1001
```

いえーあー

AMIに登録して失くさないようにする。

## 参考

- [Amazon EC2ルートボリュームのサイズを縮小してみた](https://techblog.forgevision.com/entry/2018/09/10/172633)
  - コピーの流れが図で分かり易いです。
- [EC2 EBS縮小 (というより CentOS ディスク縮小) の流れ](https://cloudpack.media/26364)
  - CentOS6(ext4)とCentOS7(xfs)のやり方。この記事がなかったら無理だった。ありがとうございます。
- [今から始めるRHEL 7 第2回 標準ファイルシステムとなったXFS](http://www.intellilink.co.jp/article/column/oss-rh02.html)
  - 問題となったXFSについての解説。
- [Linux で Amazon EBS ボリュームを使用できるようにする | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html)
- [Amazon EBS スナップショット | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EBSSnapshots.html)


CentOS7（ファイルシステムxfs）のEBSのボリュームを小さくした


アクセス元のIPをログに残したい場合、通常のApacheの設定ではLogFormatに`%h`で出力します。
ただし、ロードバランサーなどプロキシサーバを経由した場合に`%h`に出力されるIPはプロキシサーバのIP（ローカルIP）になってしまいます。

HTTPヘッダーにアクセス元のIと経由したプロキシのIPを保持する規格`X-Forwarded-For`があります。
`X-Forwarded-For`を出力することでアクセス元のIPのログを残す設定を紹介します。

ELBのApplication Load Balancerで話を進めます。

## X-Forwarded-Forを出力するconfの設定

`LogFormat`に`%{X-Forwarded-For}i`を入れます。
`%{Foobar}i`でHTTPヘッダーのFoobarの値を出力します。

```diff
-- LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
++ LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined
```

書式は`X-Forwarded-For: <client>, <proxy1>, <proxy2>`です。

[ELBとApacheの例 | aws.amazon.com](https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-capture-client-ip-addresses/)

## RemoteIPHeader X-Forwarded-Forの場合

`RemoteIPHeader` はApache内部で送信元IPを置き換えるのに使うヘッダーを指定します。

アクセス制御などのため`RemoteIPHeader X-Forwarded-For`を設定すると、`%{X-Forwarded-For}i`の中身が`‐`になりました。
この場合の書式は、`%{X-Forwarded-For}i`ではなくリモートIPアドレス`%a`とする。

例: アクセス制限している場合
```conf
RemoteIPHeader X-Forwarded-For

LogFormat "%a %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined

<Location /admin>
    AllowOverride   All
    Deny from all
    Allow from xxx.xx.xxx.x
    Allow from yyy.yyy.yy.yy/28
</Location>
```
`Allow from`で指定するIPが`X-Forwarded-For`にあるIPになるように`RemoteIPHeader X-Forwarded-For`を設定しています。
LogFormatに`%a`を加えています。

[Apache CustomLogの書式 | httpd.apache.org](https://httpd.apache.org/docs/2.4/ja/mod/mod_log_config.html)に

## IPについて

ちょうど「香川県ネット・ゲーム依存症対策条例」に関しての賛同パブコメのIPがローカルIPだったことが話題になってます。

> 「192.168.7.21」はどのような場合に表示されるのか、香川県議会事務局に聞いたところ、次のような回答がありました。
> 
> 「香川県議会ホームページにご意見・お問い合わせというフォームがあり、そこから送られたものを印刷するとどれもこのような表示になります」（議会事務局）
> 
> 事務局によると、賛成・反対を問わず、県議会ホームページの「ご意見・お問い合わせ」フォームから送信した場合は一律でこの表示になるとのこと。確かに、県のホームページ内から転送されたものであれば、プライベートIPアドレスが記載されていることにも一応の説明はつきます。
> 
> [ゲーム条例パブコメ、同一IPアドレスからの送信が多数？　原本公開で“工作疑惑”広がる → 香川県議会に見解を聞いた | ねとらぼ](https://nlab.itmedia.co.jp/nl/articles/2004/14/news081.html)

個人的に、ゲーム依存症の対策のために条例で時間制限することはやりすぎだと感じます。
この件に関してパブコメの賛同意見に水増しがあったか疑惑が残るが断定できません。
開示されたら続報が出るはず。

ここでの問題は、IPアドレス情報を残しているのに意味がない。
仮にクライアントIPを取れていたら、個人情報には当たらないけど公開するは控えたほうがいいかな。

インフラ屋としてはこういった問題が起きた場合に話題になっても恥ずかしくないインフラ設計・設定を心掛けたい。


LB経由のサーバでクライアントIPをログに残すApacheの設定 X-Forwarded-For


表題の通りAWS RDSのORACLE DBでスナップショットから新しくDBを作るとSIDが元のままだったよって報告です。

### 環境

- AWS RDS
- エンジン: Oracle Standard Edition Two

※ OracleDBに慣れていないので変な表現があるかも。

## 現象

新しくRDSのORACLE DBでスナップショットから別のDBを作りました。
手順は[スナップショットをコピー | docs.aws.amazon.com](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html)の通りです。

コピーしたスナップショットを元に「DB インスタンスの復元」を行うと**DB インスタンス識別子**を入力できます。

新しくDBを作成した場合は、DBインスタンス識別子がエンドポイントとSIDに登録されます。
コピーしたスナップショットを元に作成した場合は、SIDが元のインスタンスのままでエンドポイントのみ新しく設定した識別子でした。

DBに接続する際に気をつけてください。

```sql
SQL> SELECT INSTANCE_NAME FROM V$INSTANCE;

INSTANCE_NAME
----------------
前のSID
```

## 参考

- [Oracle SIDを確認・設定する方法](https://sql-oracle.com/?p=1706)


AWS RDSのORACLE DBでスナップショットから新しくDBを作るとSIDが元のままだった


AWSのAmazon RDSのSSL/TSL 証明書の期限が近づき更新するようアナウンスがあり、 2020/03/06 に切れるためその前に対応が必要でした。
更新にはオペレーションが必要なため、備忘録も兼ね手順を残します。

## AWSのアナウンスについて

Classmethodさんの記事が分かり易いので引用させて頂きます。

> - 2020年2月5日: 新CA証明書への強制アップデートについての通知が送付される予定日
> - 2020年2月5日〜3月5日: メンテナンスウィンドウ準拠で新CA証明書へのアップデートが実施される予定。 新CA証明書適用が実施されると短時間のダウンタイムが発生する
> - 2020年3月5日: 現行のCA証明書の利用期限日。現行のCA証明書は利用できなくなり、アップデートがこの日までに実施されていなかった場合は強制アップデートが発生する( ダウンタイム発生 )。新しいCA証明書を持っていないアプリケーションはこの日以降SSL/TLS通信が不可能になる
> 
> [Developers.IO](https://dev.classmethod.jp/cloud/aws/notification-about-certificate-rotation-for-rds-and-aurora/)より

更新には今すぐ更新と次のメンテナンスで更新かを選べます。

詳しくは、[公式](https://aws.amazon.com/jp/blogs/news/amazon-rds-certificate-rotation-2019/)か[Developers.IO](https://dev.classmethod.jp/cloud/aws/notification-about-certificate-rotation-for-rds-and-aurora/)を参照してください。

## SSL/TSL 証明書の期限の確認

データベースの「接続とセキュリティ」タブで証明書の期限を確認できます。
今回の対象は`rds-ca-2015`で以下のように認証機関の項に載っています。

![ssl](/images/posts/220/227/rds-ssl2.png)

## 証明書を更新する

証明書更新が必要なデータベースがある場合、左メニューの「Certificate update」に通知があり、
それをクリックすると更新のメニューが開きます。

![ssl](/images/posts/220/227/rds-ssl.png)

更新したいDBを選択して、即時更新したい場合は「今すぐ更新」を選択。

![ssl](/images/posts/220/227/ssl3.png)

チェックをして「今すぐ適用」をクリックすると証明書が更新されます。

![ssl](/images/posts/220/227/ssl4.png)

更新が完了すると認証機関と証明書の日付が新しくなりました。

## 更新に伴うダウンタイムについて

証明書の更新には再起動がかかるためダウンタイムが生じます。

個人的に３回実行したのでかかった時間をまとめました。

| インスタンス  | DB                          | AZ        | 再起動にかかった時間 |
| ------------- | --------------------------- | --------- | -------------------- |
| db.t3.small   | MySQL 5.6.41                | Single AZ | 11秒                 |
| db.t3.2xlarge | MySQL 5.6.41                | Single AZ | 12秒                 |
| db.t2.small   | Oracle Standard Edition Two | Single AZ | 不明?                |

- フェイルオーバーも特になく `再起動にかかった時間 = ダウンタイム` となっていました。
- 再起動にかかった時間は10秒程でインスタンスクラスの差はほぼなさそう
- アベイラビリティゾーン(AZ)がmultiの場合でも差はないそうです(Developers.IOより)
- 再起動にかかった時間は最近のイベントに`shutdown` `restarted` のログが出るためそこで確認。
  - Oracleはそのログがないため不明としている。（更新してから認証機関を見に行くと既に新しくなっていたため、体感10秒以内に完了している）
- コンソールでの手順はMySQLとOracleで違いはありませんでした。


次の証明書の期限は**2024/08/23** までです。
次回も半年ぐらい前には通知が来ると思うので早めに対応したい。

Amazon RDSのSSL/TSL 証明書を更新する


AWSのCloudFrontが期待した動作をしないときに確認するポイントを症例別にまとめます。
他の方も記事にされているため、この記事はリンク集が主です。
いくつかの私の経験したものは詳しめに書いていきます。

※書きかけなのでまだ２つです。m(__)m

## クエリ文字列が届かない 

確認する設定：**Query String Forwarding and Caching**

デフォルトではクエリ文字列を無視したキャッシュを行う`None (Improves Caching)`が設定されています。
こちらは、リクエストを処理できる可能性を高くしてオリジンの負荷を下げることができますが、**サーバ側にクエリ文字列が届かない原因**となります。

全てのクエリ文字列を渡す場合は`Forward all, cache based on all`とする必要があります。

参考：[クエリ文字列の転送とキャッシュ - 開発者ガイド](https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesQueryString)

## POSTリクエストで403 Forbidden

確認する設定：**Allowed HTTP Methods**

`Allowed HTTP Methods`が`GET, HEAD`になっているとPOST、DELETEなどのメソッドは受け付けません。
`GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE`を選びPOST、DELETEなどのメソッドをスルーさせます。

参考
- [Amazon CloudFrontによるPOSTパススルー対応きた！ ｜ DevelopersIO](https://dev.classmethod.jp/cloud/amazon-cloudfront-post-pass-through/)
- [CloudFront Form Submit Error 403 - AWS Developer Forums](https://forums.aws.amazon.com/thread.jspa?threadID=99549)

CloudFrontが期待した動作をしないときに確認する症例集


RDSでないMySQLのユーザー追加方法と同じようにマスターユーザーを追加しようとすると「権限がない」とエラーが出た。
[ドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)によると**マスターユーザーは 1 つだけしか登録できない**。
そこで、マスターユーザーと同等の権限のユーザーを作成する。

手順は[ドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)と同じですので、そちらを参照された方が良いです。

## 環境

- AWS RDS
- MySQL 5.7

設定時にマスターユーザー名を`master_user`としています。

## GRANT ALL PRIVILEGESでマスターユーザーを追加

RDSのMySQLでは`ALL PRIVILEGES`の権限をユーザーに付与させようとするとエラーが出ました。

```sql
mysql> CREATE USER 'master_user2'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.03 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'master_user2'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
ERROR 1045 (28000): Access denied for user 'master_user'@'%' (using password: YES)
```

### マスターと同等のユーザーを追加する

`ALL PRIVILEGES`では追加できませんが、ひとつひとつの権限を全て有効にしてあげればマスターと同等のユーザーにすることができます。

- ユーザー名 : `master_user2`
- パスワード : `password`
- ホスト : `%` ※ワイルドカードです。
のユーザーを追加しようとしています。

```sql
mysql> CREATE USER 'master_user2'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.06 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'master_user2'@'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.06 sec)
```

### 権限の確認

ユーザーの権限の確認方法です。

```sql
mysql> SHOW GRANTS FOR 'master_user2';
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for master_user2@%
                                                                                                                           |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE
VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'master_user2'@'%' WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)
```

### ユーザー削除

```sql
mysql> DROP USER 'master_user2'@'%';
```

### 参考

- [MySQL が実行されている Amazon RDS DB インスタンスの別のマスターユーザーを作成する方法を教えてください。](https://aws.amazon.com/jp/premiumsupport/knowledge-center/duplicate-master-user-mysql/)

AWSの公式ドキュメント

- [ユーザーに設定できる権限の種類と一覧 | MySQLの使い方 - DBOnline](https://www.dbonline.jp/mysql/user/index5.html)

権限の種類についてはこちらがわかりやすいです。

RDS MySQLでマスターユーザーを追加する


EC2のインスタンスを停止しても勝手に新しくインスタンスが作られて起動してしまうようになった。
調べていくとよくわからず設定していた**Auto Scaling**が原因だったようです。

## 症状

インスタンスがゾンビのように復活する。
ひとつのインスタンスを停止すると、新たにインスタンスが作成され起動している。
インスタンスのアクションからはそれを解消できるようなメニューは見当たらなかった。

![instance](/images/posts/160/169/instance.png)

勝手に生成されたt2.microの残骸。
(※t2.largeは別途立てたものです。)

## 原因：Auto Scaling

**原因はインスタンスをAuto Scalingのグループにアタッチしていたこと**でした。
下図のように操作を行い自動起動も設定すると同様の現象になります。

![setting](/images/posts/160/169/setting.png)

Auto Scalingはアプリケーションの負荷に応じてインスタンス数を増減できる機能です。
インスタンス数の最小サイズが１としていたため新たに起動していたようです。

参考：[Amazon EC2 Auto Scaling とは](https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)

## 解消法

EC2の左メニューにAUTO SCALINGの項があります。
まず、Auto Scalingグループを開いてインスタンスに紐づいているグループを削除します。

![auto](/images/posts/160/169/auto.png)

続いて、同じく左メニューから起動設定を開いて起動設定を削除します。
このとき、Auto Scalingグループが紐づいていると削除できません。

![up](/images/posts/160/169/up.png)

以上でゾンビインスタンスも停止することができました。

## 参考

- [AWSで停止・削除したインスタンスが勝手に再起動されて復活する](https://www.psi-net.co.jp/blog/?p=1132)
- [ELB(v2)配下のEC2を削除するとゾンビ化したインスタンスが残る](https://qiita.com/gimKondo/items/4be92db2adf395a08c97)

このふたつは、ELBを利用していたことによって同様の症状になったようです。
Auto Scalingではなかった場合は、ELBも確認してみて下さい。

EC2のインスタンスを停止しても勝手に新しくインスタンスが起動する


Amazon Linux2にPostgreSQL10を入れたとき`psql`コマンドは使えたが、操作しようとするとき下記のようなエラーが出た。

```sh
psql: FATAL:  role "ec2-user" does not exist

psql: FATAL:  Peer authentication failed for user "postgres"
```

## 環境

- Amazon Linux2
- postgres10

インストールとバージョンの確認は以下。
パッケージマネージャは`yum`ではなく`amazon-linux-extras`を利用した。

```sh
$ sudo amazon-linux-extras install postgres10
$ psql -V
psql (PostgreSQL) 10.4
```

## 現象

ec2-userで操作すると「ロールec2-userは存在しない」とエラーが出た。
`psql -l`はデータベースのリストを確認するコマンド。

```sh
[ec2-user@hostname ~]$ psql -l
psql: FATAL:  role "ec2-user" does not exist
```

そこで、psqlの初期ユーザーの`postgres`で操作を試みた。
「ユーザー”postgres”のピア認証に失敗した」とエラーがでた。

```sh
[ec2-user@hostname ~]$ psql -l -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"
```

また`root`ユーザーで試しても同様。

```sh
[ec2-user@hostname ~]$ sudo psql -l
psql: FATAL:  role "root" does not exist

[ec2-user@hostname ~]$ sudo psql -l -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"
```

## 解決策

psqlの初期ユーザーではなく、実行ユーザーのpostgresで行う。

```sh
[ec2-user@hostname ~]$ sudo -u postgres psql -l
could not change directory to "/home/ec2-user": Permission denied
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(3 rows)
```

psqlの実行権限を変更しないといけない。

### 実行権限を修正

上記のエラーは設定によるものだった。
実行権限は`pg_hba.conf`で設定できる。

```sh
# コピー
$ sudo cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.org

# 確認
$ sudo cat /var/lib/pgsql/data/pg_hba.conf
```

```conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
```

ローカルからの接続のMETHODが`peer`になっていた。
これは実行者のユーザー名とデータベースユーザー名が一致するか検査している。

METHODを`trust`にして接続を無条件で許可するか、`md5`でパスワードを求めるようにか変更すると良い。

設定の詳細はドキュメントにある。

- [PostgreSQL 10.5文書](https://www.postgresql.jp/document/10/html/auth-pg-hba-conf.html)

psql FATA role "ec2-user" does not exist｜Amazon Linux2にPostgreSQL10を入れたとき


Amazon Linux2にPostgreSQL10をインストールして初期設定するまでの手順です。
yumリポジトリにはv10があるので楽に導入できました。

2019-06-26に２回目のインストールを行いました。
この手順で大丈夫そうです。

## 環境

- Amazon Linux2
- postgresql 10.4
- postgresql-server 10.4

## インストールと立ち上げ手順

### info

まずはインストールするパッケージの確認をする。
`yum info`の情報を載せた（一部省略）。

```sh
$ sudo yum info postgresql-server postgresql

Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Installed Packages
Name        : postgresql
Arch        : x86_64
Version     : 10.4
Release     : 5.amzn2.0.2
Size        : 5.2 M
Repo        : installed
From repo   : amzn2extra-postgresql10
Summary     : PostgreSQL client programs


Available Packages
Name        : postgresql-server
Arch        : x86_64
Version     : 10.4
Release     : 5.amzn2.0.2
Size        : 4.9 M
Repo        : amzn2extra-postgresql10/2/x86_64
Summary     : The programs needed to create and run a PostgreSQL server
```

yumリポジトリに[PostgreSQLのRepository Packages](https://yum.postgresql.org/repopackages.php#pg10)を導入が必要かと思ったが、`amzn2extra-postgresql10`に入っているようです。

### install

インストールとバージョンの確認は以下のコマンドでOK。

```sh
$ sudo yum install -y postgresql-server postgresql
```

```sh
$ psql -V
psql (PostgreSQL) 10.4
```

### 起動と自動起動

現時点ではpostgresqlが立ち上がっていないため、操作しようとすると下記のようなエラーが出る。

```sh
$ psql -l
psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
```

postgresqlを立ち上げ、自動起動させます。

```sh
# 自動起動
$ sudo systemctl enable postgresql

# 起動
$ sudo systemctl start postgresql

# ステータス確認
$ sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
   Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-05-14 14:41:05 JST; 1s ago
  Process: 13572 ExecStartPre=/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS)
 Main PID: 13574 (postmaster)
   CGroup: /system.slice/postgresql.service
           ├─13574 /usr/bin/postmaster -D /var/lib/pgsql/data
           ├─13577 postgres: logger process
           ├─13579 postgres: checkpointer process
           ├─13580 postgres: writer process
           ├─13581 postgres: wal writer process
           ├─13582 postgres: autovacuum launcher process
           ├─13583 postgres: stats collector process
           └─13584 postgres: bgworker: logical replication launcher
```

停止する際は、`sudo systemctl stop postgresql`でOKです。

### 立ち上がらないとき

```sh
$ sudo systemctl start postgresql
Job for postgresql.service failed because the control process exited with error code.
See "systemctl status postgresql.service" and "journalctl -xe" for details.
```

DBの初期化が必要だった

```sh
$ sudo postgresql-setup --initdb
```

## 初期設定

psqlで操作しようとした場合下記のようなエラー出ます。

```sh
$ psql -l
psql: FATAL:  role "ec2-user" does not exist
```

これは`pg_hba.conf`の初期設定が`peer`になっているためです。
一応、実行ユーザーのpostgresで行うと回避できます。

```sh
[ec2-user@hostname ~]$ sudo -u postgres psql -l
```

- [psql FATA role "ec2-user" does not exist｜Amazon Linux2にPostgreSQL10を入れたとき](https://www.suzu6.net/posts/158-amzon-linux2-postgres-error)

### 初期パスワード

ユーザpostgresも初期パスワードの設定が必要です。

```sh
$ sudo passwd postgres
Changing password for user postgres.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
```

### postgresql.conf

`/var/lib/pgsql/data/`に設定ファイルが入っています。
`postgresql.conf`では外部に公開するためIPアドレスを変更しました。

```sh
# オリジナルを残して
$ sudo cp /var/lib/pgsql/data/postgresql.conf /var/lib/pgsql/data/postgresql.conf.org
# 編集する
$ sudo vi /var/lib/pgsql/data/postgresql.conf
```

```diff
-- #listen_addresses = 'localhost'          # what IP address(es) to listen on;
++ listen_addresses = '*'          # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost'; use '*' for all
                                        # (change requires restart)
#port = 5432                            # (change requires restart)
max_connections = 100                   # (change requires restart)
```

### pg_hba.conf

`pg_hba.conf`ではロールを設定します。

```sh
$ sudo cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.org
$ sudo vi /var/lib/pgsql/data/pg_hba.conf
```

ローカルからは認証をなくし、外部からはパスワードが必要になるよう変更します。

```diff
# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
-- local   all             all                                     peer
++ local   all             all                                     trust
# IPv4 local connections:
-- host    all             all             127.0.0.1/32            ident
++ host    all             all             0.0.0.0/0               md5
# IPv6 local connections:
-- host    all             all             ::1/128                 ident
++ #host    all             all             ::1/128                 ident
```

認証は以下の方式です。
> - Ident ： DB の所有者がシェルを実行している OS のユーザ名と一致するかで認証
> - MD5 ： PW 認証 (MD5-hashed)
> - Trust ： 認証せず、DB への接続許可 (PW スルー)
> 参考：[PostgreSQL 認証に失敗しないための Ident、MD5、Trust 比較](https://server.etutsplus.com/how-to-configure-postgresql-to-use-ident-md5-trust-authentication/)


設定が済んだら再起動します。

```sh
# 再起動
$ sudo systemctl restart postgresql
```

以上でPostgreSQL10のインストールと初期設定が終わりです。

```sh
# psqlに接続
$ psql -U postgres
```

Amazon Linux2にPostgreSQL10をインストールして初期設定する


AWS Lambdaの関数を定期的にスケジュール実行する方法についてです。
CloudWatch EventsのRateとCronの設定と記述の仕方を解説します。

PythonのコードをLambdaで実行する方法は、こちらの記事で詳しく紹介しています。

[AWS LambdaにPythonコードをzipでアップロードして実行する方法を詳しく](https://www.suzu6.net/posts/83-lambda-zip/)

## CloudWatch Eventsを使ったスケジュール実行の概要

AWS Lambdaの関数は**CloudWatch Events**をトリガーに実行できます。
CloudWatch Eventsには、「イベントパターン」と「スケジュール式」の２つのタイプがあり、定期的に実行するためには「スケジュール式」を使います。

### RateとCron

スケジュール式の記述の仕方は**Rate**と**Cron**があります。
簡単に書く場合はRateを、曜日や時間帯を制限する複雑な処理をする場合はCronを使います。

間隔が１分より短い設定はできません。

## Rate

[rate式](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/ScheduledEvents.html#RateExpressions)

**構文**

```sh
rate(正数 単位)
```

| 変数 | 説明                                                                 |
| ---- | -------------------------------------------------------------------- |
| 正数 | 正数。                                                               |
| 単位 | 時刻の単位。有効な値: `minute | minutes | hour | hours | day | days` |

### 例

```sh
# 5分ごと
rate(5 minutes)

# １時間ごと
rate(1 hour)

# 7日ごと
rate(7 days)
```

時間の間隔は分かりますが、開始のタイミングは指定できない？
ドキュメントにも記述がなかった（見つけられなかった）ので、試してから追記します。

### 注意点

気をつける点は、**時刻の単位が単数形と複数形で分ける必要があること。**
単数形と複数形と複数形を間違えてもバリデーションチェックは効かないので注意してください。

```sh
# OK
rate(1 hour)
rate(30 minutes)

# NG
rate(1 days)
rate(10 minute)
```

### 単位を間違えると

明らかな構文エラーの場合は知らせてくれます。

![mistake](/images/posts/136/mistake.png)

`rate(1 hours)`のような単位の間違えはフォームで検知できませんでした。
登録後に表示されます。

![rate-error](/images/posts/136/rate-error.png)

## Cron

[cron式](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/ScheduledEvents.html#CronExpressions)

**構文**

６つの必須フィールドがあります。

```sh
cron(分 時 日 月 曜日 年)
```

| フィールド | 値                  | ワイルドカード |
| ---------- | ------------------- | -------------- |
| 分         | 0-59                | , - * /        |
| 時間       | 0-23                | , - * /        |
| 日         | 1-31                | , - * ? / L W  |
| 月         | 1-12 または JAN-DEC | , - * /        |
| 曜日       | 1-7 または SUN-SAT  | , - * ? L #    |
| 年         | 1970-2199           | , - * /        |

Linuxの[crontabの設定](https://qiita.com/amachan/items/53553de87be26a98ab8f)に`年`を追加しています。

### 例

```sh
# 毎日午前10時に実行
cron(0 10 * * * *)

# 10分ごとに実行
cron(*/10 * * * * *)

# 02分、32分に実行
cron(2/30 * * * * *)

# 毎週月曜日から金曜日の0時0分に実行
cron(0 0 * * MON-FRI *)

# 毎月第１月曜日の午前９時に実行
cron(0 9 * * 2#1 *)
```

### ワイルドカード

ワイルドカードの機能を整理しました。

| ワイルドカード | 説明                                               | 例                                                                                        |
| -------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| ,              | 追加の値が含まれる。                               | 月の`JAN,FEB,MAR`は１月、２月、３月を含む。                                               |
| -              | 範囲を指定する。                                   | 日の`1-15`は、指定した月の １日から15日を含む。                                           |
| *              | フィールドのすべての値が含まれる。                 |                                                                                           |
| /              | 増分を指定する。                                   | 分の`1/10`は、その時間の最初の1分から始めて10分毎を指定できる(11分、21分、31分など)。     |
| ?              | いずれかを意味する。                               | 日に`7`と入力し、７日が何曜日であってもかまわない場合、曜日に`?`を入力できる。            |
| L              | 月または週の最終日を指定する。                     |                                                                                           |
| W              | 平日を指定する。                                   | 日で`3W`は月の３番目の平日に最も近い日を指定する。                                        |
| #              | 月の指定された曜日の特定のインスタンスを指定する。 | `3#2`は月の第２火曜日を示す。`3`は３番目の曜日 (火曜日) を示し、`2`は月の何週目かを示す。 |

## CloudWatch Eventsの設定手順

CloudWatch Eventsの設定方法を説明します。

Lambdaの関数の左のトリガーから**CloudWatch Events**を選択します。

![selected-cw-events](/images/posts/83/selected-cw-event.png)

CloudWatch Eventsをクリックしてトリガーを設定していきます。

![setting-cw-events](/images/posts/83/setting-cw-event.png)

「ルールタイプ」から「スケジュール式」を選択して、スケジュール式を書きます。

```sh
# Cronの02分、32分で実行する処理
cron(2/30 * * * ? *)
```

登録するとこうなります。

![set-cw-events](/images/posts/83/set-cw-event.png)

### 実行した日時の記録

Eventの詳細からLambdaを実行した日時の記録が見られます。

![cron](/images/posts/83/cron.png)

### 補足：CloudWatch Eventsのイベントパターン

イベントパターンの場合は、これらのイベントから発火できます。

![role](/images/posts/136/role.png)

EC2のインスタンス作成・停止やオートスケールに対して処理を行えます。

## こちらもどうぞ

- [AWS LambdaにPythonコードをzipでアップロードして実行する方法を詳しく](https://www.suzu6.net/posts/83-lambda-zip/)
- [OpenWeatherMapで都市名から気象情報を取得する](https://www.suzu6.net/posts/78-owm)  
- [【Python】Boto3でDynamoDBにデータを保存する](https://www.suzu6.net/posts/80-boto3-dynamodb/)
- [Zappaを使ってPythonのコードをAWS Lambdaにデプロイする](https://www.suzu6.net/posts/4/)

<a target="_blank"  href="https://www.amazon.co.jp/gp/product/4798155160/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4798155160&linkCode=as2&tag=suzu60c-22&linkId=0aa0dcdab1ea33af2c32b879eb2510a3"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&MarketPlace=JP&ASIN=4798155160&ServiceVersion=20070822&ID=AsinImage&WS=1&Format=_SL160_&tag=suzu60c-22" ></a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=suzu60c-22&l=am2&o=9&a=4798155160" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />

AWS Lambdaで定期処理を実行するためのRateとCronの設定


Pythonで書いたコードを**zipにまとめてAWS Lambdaで実行する**方法について紹介します。
pipでインストールしたモジュールも一緒にLambdaにアップロードします。

個人的な興味として、気象情報を取得してDynamoDBに保存するコードを**定期的に実行する方法**も書きます。こういったバッチ処理を切り出すとメインサーバの負荷が減ったり、コードの見通しが良くなり保守性も上がります。

- [OpenWeatherMapで都市名から気象情報を取得する](https://www.suzu6.net/posts/78-owm)  
- [【Python】Boto3でDynamoDBにデータを保存する](https://www.suzu6.net/posts/80-boto3-dynamodb/)

この２つの続きであり、目標は気象データのAPIを作成することです。



### 環境

- Linux Mint (Mac, Windows 10でも動作確認済み)
- Python 3.6

## Lambdaで動かすための準備

ローカルにて作成したコードをLambdaで動かすための準備をします。

### Lambdaで外部モジュールを利用するには？

LambdaではPythonコードを直接書いて（インラインコード）実行することが出来ます。
ただし、この場合は外部モジュールをpipでインストールすることは出来ません。
そこで、コードとモジュールをzipでまとめてアップロードする必要があります。

手作業でzipにまとめる場合は、まずモジュールをコードと同じディレクトリにインストールします。

### pipでカレントディレクトリにインストールする

pipでコードと同じディレクトリにインストールします。
[前回](https://www.suzu6.net/posts/80-boto3-dynamodb/)作成したコードに必要なモジュールを用意していきます。
以下の２つをインストールする。

- boto3
- requests

実行ファイルのあるディレクトリに移動して、オプション`-t`で指定の場所にモジュールをインストールする。

```sh
$ cd [実行ファイルのディレクトリ]
$ pip install boto3 -t ./
$ pip install requests -t ./
```

そうすると以下のようなファイルが置かれます。
`lambda_function.py`は前回製作したLambdaで実行するメインコード。

```sh
$ ls
bin                           chardet                  jmespath                         s3transfer
boto3                         chardet-3.0.4.dist-info  jmespath-0.9.3.dist-info         s3transfer-0.1.13.dist-info
boto3-1.9.86.dist-info        dateutil                 lambda_function.py               six-1.12.0.dist-info
botocore                      docutils                 __pycache__                      six.py
botocore-1.12.86.dist-info    docutils-0.14.dist-info  python_dateutil-2.7.5.dist-info  urllib3
certifi                       idna                     requests                         urllib3-1.24.1.dist-info
certifi-2018.11.29.dist-info  idna-2.8.dist-info       requests-2.21.0.dist-info
```

一度、`lambda_function.py`を実行して確認してみてください。

## 実行権限を変更する

Lambdaが実行できるようにファイルの権限を変更します。

755をつけます。
実行と読みこみの権限があれば大丈夫です。

```sh
$ chmod -R 755 ./*
```

`-R`はディレクトリ内も再帰的に処理します。

## zipに圧縮してまとめる

続いて、Lambdaにアップロードするためコードとモジュールをzipにまとめます。
コマンドでも圧縮ツールでまとめるてもどちらでも良いです。

この時、コードのディレクトリ内のファイルを選択してzipにして下さい。
ディレクトリを選択してzipにすると、１階層分深くなりLambdaのハンドラが読めません。
（Lambdaの設定で回避できそうだが、上手くいかなかった。）

### ツールで圧縮する。

ツールで圧縮しても大丈夫です。
ただし、Windowsの場合は[AWSのドキュメント](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/deployment-package-v2.html)にある通り[７-ZIP](https://sevenzip.osdn.jp/)でzip化することが推奨されています。

![windows-zip](/images/posts/83/windows-zip.png)

図のように、ディレクトリ内のファイルを選択してzipにして下さい。

### コマンドでzipにする。（LinuxまたはMac)

以下のコマンドでzipにできます。

```sh
$ cd [実行ファイルのディレクトリ]
$ zip -r zip_file ./*
```

`zip_file.zip`というファイルができているはずです。
ファイル名は適宜変更して構いません。

zipコマンドの詳細は[こちら](https://www.suzu6.net/posts/63-zip-command/)。

## AWS Lambdaを用意する

続いてAWS Lambdaを用意していきます。

### Lambda関数を作成する

AWSコンソールのサービスからLambdaを選びます。
「ダッシュボード」か「関数」から「関数の作成」ボタンを押してLambda関数を作成します。
この後は「一から作成」の手順を解説します。

それぞれ項目を記入していきます。

![lambda-setting](/images/posts/83/lambda-setting.png)

Pythonのランタイムは2.7、3.6、3.7とあり利用したいバージョンを選びます。
バージョンは後からも変更可能です。
（図では3.7を選んでいますが3.6で前回作ったことを思い出して、後で変更しました。）

ロールは既存のロールを選択して、「microService」を選んでみました。
**DynamoDBの操作**と**定期実行するためのCloudWatch Events**を利用できます。

下図は関数を作成後の初期画面です。
左がLambdaを実行するトリガー、右がLambdaが操作できるサービスです。
選択できるサービスはロールの「microService」が権限を持つものです。

![lambda-init](/images/posts/83/lambda-init.png)

### CloudWatch Eventsを設定して定期実行する

定期実行するために左のトリガーから**CloudWatch Events**を選択します。

![selected-cw-events](/images/posts/83/selected-cw-event.png)

CloudWatch Eventsがトリガーとして追加されました。
CloudWatch Eventsをクリックすると実行する時間を設定できます。

![setting-cw-events](/images/posts/83/setting-cw-event.png)

```
cron(2/30 * * * ? *)
```

利用するOpenWeatherMapのAPIの更新頻度が30分間隔なので、スケジュールも30分ごとに設定しました。
ちょうどだと更新出来ていないことがあるので、2分待ってから取得する設定です。

AWS公式による設定の詳細は[こちら](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/tutorial-scheduled-events-schedule-expressions.html)。

設定が終わるとこうなります。

![set-cw-events](/images/posts/83/set-cw-event.png)

---

追記：Eventの詳細で実行した日時の記録が見れました。設定は間違っていないようです。

![cron](/images/posts/83/cron.png)

---

Lambdaの設定は以上です。

## zipファイルをLambdaにアップロードする

間が空きましたが、作成したzipファイルをLambdaにアップロードします。

![zip-upload](/images/posts/83/zip-upload.png)

「アップロード」ボタンからzipファイルを選んでアップロードします。

### ファイルサイズの制限とAmazon S3経由でのアップロード

この方法では、ファイルサイズに10MBまでの制限があります。
それ以上に大きい場合は、一度**S3**を経由してLambdaへアップロードすることになります。
「コード エントリ タイプ」を変更して、Amazon S3 のリンク URLを張り付けます。

![via-s3](/images/posts/83/via-s3.png)

### ハンドラの設定

「ハンドラ」はLambdaが実行する関数を指定する箇所です。

デフォルトでは`lambda_function.lambda_handler`となっています。
これは`lambda_function.py`の`lambda_handler()`という関数を実行します。

[前回](https://www.suzu6.net/posts/80-boto3-dynamodb/)作ったコードもデフォルトに合わせてあります。
また、zipファイルを作成するとき階層を意識してzip化したのもこのためです。

アップロードが終わったら、上部の「保存」を押してコードを保存して下さい。

## Lambda関数をテストしてみる。

以上で実行できるはずです。
大丈夫かどうかテストしてみます。

「保存」ボタンの横に「テスト」があるので押します。

![test](/images/posts/83/test.png)

こんな感じになりますが、今回のコードはパラメータを受け取るタイプではないので適当に作っても実行できます。
イベント名をつけたら保存します。

先ほど作ったテストイベントを選んで「テスト」を押すと実行できます。

![success](/images/posts/83/success.png)

成功するとこうなります。
詳細を開くと`print()`で出力したログが出るのでちゃんと動いているか確認できます。

### 処理に失敗した場合

失敗した場合はエラーログを確認してください。
よくあるのは`permission denied`でファイルの実行権限がない。また、「ファイルもしくは関数が見つかりません」です。
ディレクトリ構造と権限を見直して何度が試してみてください。

スケジュール実行は待ってみて結果が解ると思います。

## おわりに

以上で定期的に気象データを取得してDynamoDBに貯めることが出来ました。

zipでLamdaにあげる以外にも、**zappa**を使ってコマンドで行う方法もあります。
zappaはモジュールをまとめるだけでなく、API Gatewayなども自動で用意させることも出来ます。
そちらを知りたい方は、[Zappaを使ってPythonのコードをAWS Lambdaにデプロイする](https://www.suzu6.net/posts/4/)を見てください。

## こちらもどうぞ

- [OpenWeatherMapで都市名から気象情報を取得する](https://www.suzu6.net/posts/78-owm)  
- [【Python】Boto3でDynamoDBにデータを保存する](https://www.suzu6.net/posts/80-boto3-dynamodb/)
- [Zappaを使ってPythonのコードをAWS Lambdaにデプロイする](https://www.suzu6.net/posts/4/)

<a target="_blank"  href="https://www.amazon.co.jp/gp/product/4798155160/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4798155160&linkCode=as2&tag=suzu60c-22&linkId=0aa0dcdab1ea33af2c32b879eb2510a3"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&MarketPlace=JP&ASIN=4798155160&ServiceVersion=20070822&ID=AsinImage&WS=1&Format=_SL160_&tag=suzu60c-22" ></a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=suzu60c-22&l=am2&o=9&a=4798155160" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />


AWS LambdaにPythonをモジュール毎zipでアップロードする方法


OpenWeatherMapで取得したデータを**DynamoDB**に保存します。
Pythonでコードを書き、**AWS Lambda**を使って定期的に気象情報を保存することを目的としています。
DynamoDBの操作はAWSのSDKである**Boto3**を利用しました。

[OpenWeatherMapで都市名から気象情報を取得する](https://www.suzu6.net/posts/78-owm)の続きです。  
[ファイルの権限を変更できない。Googleドライブのシンボリックリンクが原因でした](https://www.suzu6.net/posts/79-mac-chmod-700) こんなこともあったので環境を少し変えています。

今回はローカルからBoto3でデータを保存するところまで。

### 環境

- Mac
- Python 3.6
- Boto3  :  v1.9.86
- Requests : v2.21

Requestsはインストール済みとします。

## Boto3

- [AWS SDK for Python - Amazon.com](https://aws.amazon.com/jp/sdk-for-python/)
- [github](https://github.com/boto/boto3)

AWS謹製のPythonモジュール。
Boto3を利用するとAmazon S3、Amazon EC2、Amazon DynamoDB などAWSの各種サービスと容易に統合できます。

ドキュメントは[こちら](https://boto3.readthedocs.io/)

### インストール方法

pipでインストールできます。

```sh
$ pip install boto3
```

## DynamoDBにテーブルを用意する

DynamoDBは**NoSQL**です。
PostgreSQLなどの**リレーショナルDB**とデータの持ち方が違うため、まずそれ用のテーブルの設計をします。

### テーブル設計

保存したいのは気象情報の時系列データです。
また、複数の観測点がありそれぞれ都市名が付いています。

よって、**プライマリパーティションキー**を`city_name (文字列)`、**プライマリソートキー**を`timestamp (数値)`にしました。
これで、都市ごとのとある期間のデータをまとめて取得できるはず。

その他の項目は自由に追加できます。
気象データは項目`data`にJSON形式でぶち込む予定です。

![hongkong](/images/posts/80/hongkong.png)

登録してみた香港の気象データ。
dataの中身は変更があると思うので適当。

テーブル名は`current-weather`とした。
scanなどテーブル全体の操作で無駄を減らすため、月ごとにテーブルを分けていく。
年月をつけて`current-weather.201901`とした。


### テーブルを作成する

設計を基にDynamoDBに気象情報を溜め込むテーブルを作成します。
リージョンは**アジアパシフィック（東京）**にしています。

![createdb](/images/posts/80/createdb.png)

ダッシュボードからテーブルを作成する。

![init-dynamodb](/images/posts/80/init-dynamodb.png)

テーブル名、プライマーキーを設定する。
ソートキーとしてtimestampを登録した。

## AWSのアクセスキーを取得する。

セキュリティのため、AWSの各種サービスの操作にはアクセスキーが必要です。
DynamoDBの読み書きやテーブルの作成するため`AmazonDynamoDBFullAccess`を持ったユーザーのアクセスキーを取得します。

マスターユーザーで試すことは良いですが、アクセスキーが流出したとき[えらいこと](https://qiita.com/mochizukikotaro/items/a0e98ff0063a77e7b694)になるので権限を絞ったユーザーを使います。

サービスの**IAM**から、左メニューの「ユーザー」→「ユーザーを追加」から気象情報をDynamoDBに書き込むユーザーを追加します。

![user-name](/images/posts/80/user-name.png)

名前を`weatherAPI`として「プログラムによるアクセス」をチェックする。

![policy](/images/posts/80/policy.png)

「既存のポリシーを直接アタッチ」を選んで、`AmazonDynamoDBFullAccess`を探してチェックします。
データを読むだけなら`AmazonDynamoDBReadOnlyAccess`があります。

![access-key](/images/posts/80/access-key.png)

必要であればタグを付け、進めるとアクセスキーが表示されます。
**アクセスキーID**と**シークレットアクセスキー**を保存してください。
シークレットアクセスキーはここでしか見ることができない（はず）です。
csvも保存できます。

くれぐれも、[GitHubにアクセスキーを上げないよう気をつけて](https://qiita.com/saitotak/items/813ac6c2057ac64d5fef)ください。

※ 正直このセキュリティ関連は詳しくないため、公式や他のサイトも参考にしてください。

## プログラムからデータを保存する

やっと本題。
気象情報を取得する部分は[前回](https://www.suzu6.net/posts/78-owm)作成したコードを使います。

全体像は、定期的に気象情報を取得して保存するプログラム。

- 複数の都市名をキーに現在の気象情報を取得する。
- データを整形する。
- 都市名をパーティションキーにしてDynamoDBに保存する。

※ テーブルを月ごとに分けるよう設計していますが、テーブルの作成はまだ機能していません。

以下のソースコード部分を繋いで一つのファイルにすると実行できます。

### 使用するモジュール

```python

"""
OpenWeatherMapから現在の気象データを取得してDynamoDBに保存する。
"""

import boto3    # AWSのSDK
import requests # OpenWeatheMapのAPI取得
import json
import datetime
import decimal  # DynamoDB用にFloat型をDecimal型に変換する
```

**boto3**をインポートする。
DynamoDBにFloat型がないためDecimal型に変換するように**decimal**を利用する。decimalは標準モジュール。

### 気象情報の取得

詳細は[前回](https://www.suzu6.net/posts/78-owm)を見てください。

```python
def getWheather(city_name):
    API_KEY = "xxxxxxxxxxxxxxxxxxxxxxxx"  # xxxにOWMのAPI Keyを入力。
    api = "http://api.openweathermap.org/data/2.5/weather?units=metric&q={city}&APPID={key}"

    url = api.format(city=city_name, key=API_KEY)
    print(url)

    response = requests.get(url)
    # APIレスポンスの表示
    jsonText = json.dumps(response.json(), indent=2)
    print(jsonText)

    return response.json(parse_float=decimal.Decimal) # dict型に変換する際にFloatをDecimalにする
```

Requestsで受け取ったresponseを**dict型**にする際、Float型をDecimal型にします。
そうしないと以下のエラーが出ます。

```error
TypeError: Float types are not supported. Use Decimal types instead.
```

参考：[DynamoDB x Python / Decimal を登録する](https://qiita.com/dskst/items/10ea3f0d5899d058734e)

### データを整形する

DynamoDBのテーブルに合わせてデータを整形する。

```python

def formatter(response):
    data = response
    # 表示用時刻
    unix = data["dt"]
    now = datetime.datetime.fromtimestamp(unix)

    # 保存するデータを作成
    item = {
        'city_name': data['name'],  # プライマリパーティションキー
        'timestamp': data["dt"],   # プライマリソートキー
        'datetime': now.strftime("%Y-%m-%dT%H:%M:%S"),
        'latitude': data['coord']['lat'],
        'longitude': data['coord']['lon'],
        'data': {
            'weather': data['weather'],
            'temp': data['main']['temp'],
            'humidity': data['main']['humidity'],
            'pressure': data['main']['pressure'],
            'clouds': data['clouds']['all'],
            'wind': data['wind']
        }
    }
    return item
```

itemの形式で保存される。
timestampはUNIX時間。

### DynamoDBへ登録する

前半にDynamoDBと接続をして、後半にitemを保存している。

先ほど登録したAWSのユーザーのアクセスキーを渡す。
コードに書きたくない場合は、設定ファイルや環境変数に登録して使うと良い。

```python

def insert(items):
    # データベース接続の初期化
    session = boto3.session.Session(
        region_name='DBのリージョン',
        aws_access_key_id='アクセスキーID',
        aws_secret_access_key='シークレットアクセスキー'
    )
    dynamodb = session.resource('dynamodb')

    # tableのパーティション用
    now = datetime.datetime.now()
    ym = now.strftime("%Y%m")

    # テーブルと接続
    table_name = 'current-weather.' + ym
    table = dynamodb.Table(table_name)

    for item in items:
        # 追加する
        response = table.put_item(
            TableName=table_name,
            Item=item
        )
        if response['ResponseMetadata']['HTTPStatusCode'] is not 200:
            # 失敗処理
            print(response)
        else:
            # 成功処理
            print('Successed :', item['city_name'])
    return
```

`table.put_item()`ではなく`table..batch_writer()`を使い一括で登録しても良さそう。

### 本体部分

取得する都市の名前をリストで持ち、順次処理していく。

```python

def weather_api(cities):
    items = []

    for city_name in cities:
        response = getWheather(city_name)

        if response['cod'] is not 200:
            print(city_name, ', status code :',
                  response['cod'], response['sys']['message'])
            continue
        item = formatter(response)
        print(item)
        items.append(item)

    insert(items)
    return True


def lambda_handler(event, context):
    # 都市と送信先を指定する。
    # OWMで指定可能な都市名は以下で確認する。
    # https://openweathermap.org/weathermap?basemap=map&cities=true&layer=temperature&lat=44.0079&lon=144.2487&zoom=12
    cities = [
        'Sapporo',
        'Tokyo',
        'Osaka-shi',
        'Okinawa',
        'Hong Kong',
        'New York',
        'City of London'
    ]
    weather_api(cities)

    return


if __name__ == "__main__":
    lambda_handler(None, None)

```

## 終わりに

無事にDynamoDBに気象データを保存することができました。
続いてはAWS Lambdaにあげて定期的に取得するように自動化していきます。

[AWS LambdaにPythonコードをzipでアップして実行する方法を詳しく](https://www.suzu6.net/posts/83-lambda-zip)

【Python】Boto3でDynamoDBにデータを保存する

静的サイトを作る上でホスティングサービスの検討とNetlifyを使ってみた感想




## この記事について

こんにちは、suzu6です。

本ブログはAWSの**Lambda**と**DynamoDB**を使って、サーバレスなシステム構成になっています。

現在の構成はこちら

![アーキテクチャ](https://www.suzu6.net/images/posts/7/blog-website_constitution.svg)

Lambdaのところに、PythonのFlaskで作ったシステムがのっています。全体像は[こちら](https://www.suzu6.net/posts/2)で解説しています。

この記事では、DynamoDBを使う中で感じた、特徴とLambdaとの相性を紹介します。  

## DynamoBDの特徴

- NoSQLでタイプはキーバリューストア型
- 自動的なスケールアップ。
- 読み込み書き込みが早い。
- プライマリキーは`HASH` か `HASH + RANGE`の２通り
- コピーを３箇所に分散して保管してくれる
- SQLではなく、APIで操作する。
    - SQLに比べて、学習コストが高い。

## NoSQLなDynamoDB

![DynamoDB](https://www.suzu6.net/images/posts/35/DynamoDB.png)

**DynamoDBはNoSQL**であり、（馴染み深い）Postgresqlなどのリレーショナルデーターベースとは大きく異なります。

> [NoSQL データベースとは](https://aws.amazon.com/jp/nosql/)  
> NoSQL データベースは、スケーラブルなパフォーマンスとスキーマレスなデータモデル向けに最適化された非リレーショナルデータベースです。

NoSQL データベースには、列指向、ドキュメント、グラフ、キーバリューストアという4つのタイプがあります。
その内、DynamoDBはキーバリューストア（Kye-Value Store）にあたります。

キーバリューストアは、保存する情報（value）に識別記号（key）をつけて管理しようというもの。
保存できる情報を固定化せず大小様々なものを保管し、検索するときに識別記号だけ見みます。

## AWS LambdaとDBの相性について

AWSで利用できるデータベースは、Postgresなどが使える`RDS`とNoSQLの`DynamoDB`があり、この２つを比較しました。　　
(調査不足のため`RedShift`は考えていませんでした。。。)

`Lambda`の特徴は、リクエスト受信の回数に合わせて自動的にスケールすることです。
ブログへリクエストが頻発すると、データベースへのアクセス数も多くなります。

ここで、RDSでは接続数が問題になります。
当然ながら同時に接続される数が多ければ多いほど必要なCPU数、メモリ数が増えていきます。

また、DBへ都度接続することは負荷になるため、一般的にはコネクションプールを使って接続を使いまわします。
しかし、Lambdaは処理が終われば接続は切れますし、接続を共有することもありません。

RDSではピークの処理に合わせて始めから大きなスケールアップが必要となります。
よって、Lambdaとの相性はよくありません。

一方、`DynamoDB`はLambdaと同じくスケーリングが可能です。  
そのため、Lambdaと合わせるDBはDynamoDBを選ぶと良いです。

さらに詳しくは、[こちら](http://keisuke69.hatenablog.jp/entry/2017/06/21/121501)をご参照ください。

## 設計のポイント

- プライマリーキーを3つ以上指定できない
- プライマリーキー以外でのソートはできない
- 空文字が利用出来ない
- テーブル結合した検索はできない
- 複雑なデータ更新の多いシステムの利用には向かない
- キャパシティユニットは自動ではスケールしない
- 一回の検索で得られるのは１MBまで


## 使ってみた感想

本ブログでは、記事やタグの管理をDynamoDBを使っています。  
PV数も月に数百PVくらいなので、スケールアップの恩恵はまだ受けていませんが、料金が無料利用枠に十分収まっています。

良い点は、コンソール画面が使いやすいところでしょうか。
ちょっとした編集やテスト用の項目を手軽に消したりできます。

困った点は、SQLが使えずライブラリの[boto3](https://boto3.readthedocs.io/en/latest/)を利用したところです。
SQLならこう書くのにとすぐ思い浮かんでも、DynamoDBとboto3の書き方を頑張って調べて、英語のドキュメントも読んでどうにか実装していきます。
学習コストが高い点が最大の壁かもしれません。

もう一点困ったことは、ページネーションです。  
SQLでは、`offset`と`limit`を使って取得する範囲と件数を簡単に書けます。
DynamoDBでは、boto3のPagenatorを利用するようです。
情報が少なくまだ理解しきれてないため、現在はscanで全件取得して必要な範囲を得ています。

重そうな処理ですが、記事数が少ないためか、記事一覧のページネーションが意外とサクサク動いています。
今後、ベストな方法に変更していきたいです。


## 参考

- [なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する](http://keisuke69.hatenablog.jp/entry/2017/06/21/121501)
- [NoSQL データベースとは](https://aws.amazon.com/jp/nosql/) 
- [何が違う？DynamoDBとRDS](http://blog.serverworks.co.jp/tech/2017/04/12/what_is_different_dynamodb_and_rds/) 
- [AWS DynamoDBのページング ](https://www.magata.net/memo/index.php?AWS%20DynamoDB%A4%CE%A5%DA%A1%BC%A5%B8%A5%F3%A5%B0)

---

サーバレスアーキテクチャを勉強される方は、こちらの本がおすすめです。
<div class="amakuri-default-comment" style="text-align: left; line-height: 1.5em; margin-bottom: 10px; overflow:hidden; _zoom:1;"><div class="amakuri-default-comment-image" style="float: left; margin: 0 20px 0 0;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank"><img src="https://images-fe.ssl-images-amazon.com/images/I/51L3N%2B3pL1L._SL160_.jpg" width="128" height="160" alt="AWSによるサーバーレスアーキテクチャ" style="border: none"></a></div><div class="amakuri-default-comment-desc" style="overflow: hidden; _zoom:1;"><div class="amakuri-default-comment-title" style="margin-bottom: 0.5em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">AWSによるサーバーレスアーキテクチャ</a></div><div class="amakuri-default-comment-posted" style="margin-bottom: 0.5em; font-size: small;">Posted at 2018.12.21</div><div class="amakuri-default-comment-author">Peter Sbarski</div><div class="amakuri-default-comment-label" style="margin-bottom: 0.5em;">翔泳社</div><div class="amakuri-default-comment-link" style="margin-top: 1em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">Amazonで詳細を見る</a></div></div></div>

動画シェアサイトをAWS Lambda, S3を使って実際に構築する手順が載っています。
その中で、どのようにLambdaを構成したら良いか大変参考になりました。また、DynamoDBとAuth0も詳しく書かれています。

AWS DynamoDBの特徴とLambdaとの相性+使ってみた感想


2018年12月にブログを移行した際にこの機能は削除しました。

## はじめに

解析の勉強のため、このブログの統計情報を集めようと思い立ちました。  

手始めに、記事のアクセス時刻や利用しているブラウザなどの情報を取得します。
本ブログは、Python + Flaskで構築しているため、**Flask request**を利用します。

この記事では、記事のページを見るユーザーの情報をFlask requestで集め、DynamoDBに保存するところまで設計します。

普段使っている、**Google Analytics**が高機能すぎますね。
調べると、[Core Reporting API](https://developers.google.com/analytics/devguides/reporting/core/v3/?hl=ja)で色々できるみたいです。
追々差別化できるようにしないと。。。

実装編はこちら

[リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-2.実装編](https://www.suzu6.net/posts/34)

## 概要

Flaskは、`request.environ`にアクセス元の情報がまとめられています。
そこから情報を取り出し、DynamoDBに保存します。

Flaskについては、以前の記事[[Python] Flask入門とサーバレスアーキテクチャ](https://www.suzu6.net/posts/6)をご覧下さい。

## 環境

```sh
$ python --version
Python 3.6.5
$ pip show Flask
Name: Flask
Version: 1.0.2
```

## request.environの中身

ちょうど良いドキュメントが見つからないので、直接見てしまいましょう！

```python
print(request.environ)
```

これで表示したものを、見やすくjsonに加工したものが以下になります。

```json
{
    "wsgi.version": (1,0),
    "wsgi.url_scheme": "http",
    "wsgi.input": <_io.BufferedReader name=5>,
    "wsgi.errors": <_io.TextIOWrapper name="<stderr>" mode="w" encoding="UTF-8">,
    "wsgi.multithread": True,
    "wsgi.multiprocess": False,
    "wsgi.run_once": False,
    "werkzeug.server.shutdown": <function WSGIRequestHandler.make_environ.<locals>.shutdown_server at 0x10f00c950>,
    "SERVER_SOFTWARE": "Werkzeug/0.14.1",
    "REQUEST_METHOD": "GET",
    "SCRIPT_NAME": "",
    "PATH_INFO": "/article/8",
    "QUERY_STRING": "",
    "REMOTE_ADDR": "127.0.0.1",
    "REMOTE_PORT": 62057,
    "SERVER_NAME": "127.0.0.1",
    "SERVER_PORT": "5000",
    "SERVER_PROTOCOL": "HTTP/1.1",
    "HTTP_HOST": "127.0.0.1: 5000",
    "HTTP_CONNECTION": "keep-alive",
    "HTTP_PRAGMA": "no-cache",
    "HTTP_CACHE_CONTROL": "no-cache",
    "HTTP_UPGRADE_INSECURE_REQUESTS": "1",
    "HTTP_USER_AGENT": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36",
    "HTTP_ACCEPT": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
    "HTTP_REFERER": "http://127.0.0.1:5000/contents/Google%20Adsence",
    "HTTP_ACCEPT_ENCODING": "gzip, deflate, br",
    "HTTP_ACCEPT_LANGUAGE": "ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7",
    "HTTP_COOKIE": "gsScrollPos-1901=; gsScrollPos-2345=0; gsScrollPos-1735=0; _ga=GA1.1.1286324805.1530497168; session=eyJ1c2VybmFtZSI6ImFkbWluIn0.Dh3nXg.HvlJWyVbh3Zsa2-6fEi_lMVaDJo; _gid=GA1.1.316787490.1532584271; _gat_gtag_UA_106883433_1=1",
    "werkzeug.request": <Request "http://127.0.0.1:5000/article/8" [GET]>
}
```
※ local環境でChromeからテストした情報です。

httpのヘッダーの情報が入っていることがわかります。
Google Analyticsもきっと、ヘッダーの情報を収集しているんでしょうね。


貯めておくと面白そうな情報が色々ありました。

key|説明|value
---|-----|-----------
REMOTE_ADDR|IPアドレス|127.0.0.1
HTTP_USER_AGENT|ブラウザやOSの情報|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
HTTP_CONNECTION|継続したコネクションかどうか|keep-alive
PATH_INFO|URLのパス|/article/8


## 取得する項目とDynamoDBのテーブル設計

以下の項目を取得します。
DynamoDBのテーブル設計も兼ねます。


Table: page_view_logs

field name|primary key|説明
----------|-----------|----
article_id|hash key|記事のID
view_at|range key|閲覧時刻'%Y-%m-%d %H:%M:%s'日本時間
remote_addr|　|IPアドレス
browser|　|利用したブラウザ
user_os|　|osの種類
is_keep_alive|　|継続したコネクションか


記事毎に集計できるように、記事IDと閲覧時刻をプライマリーキーにしました。この２項目は、URLとdatetimeから得ます。

６項目を取得していきます。

---

実装編はこちら

[リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-2.実装編](https://www.suzu6.net/posts/34)

---
本ブログの構成について

- [AWSで始めるサーバレスなブログサービス](https://www.suzu6.net/posts/2)
- [CroudFrontとAPI Gatewayで自作ブログサイトを改善しました](https://www.suzu6.net/posts/7)
- [[Python] Flask入門とサーバレスアーキテクチャ](https://www.suzu6.net/posts/6)


リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-1.設計編


2018年12月にブログを移行した際にこの機能は削除しました。

## はじめに

解析の勉強のため、このブログの統計情報を集めようと思い立ちました。  

この記事は、設計編からの続きとなります。

[リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-1.設計編](https://www.suzu6.net/posts/33)

機能を実装していきましょう。

## ブログに実装する


記事にリクエストがきた場合は、記事IDとreuestsを`VieLogsManager`に渡します。
`insert()`が、記事の閲覧履歴を追加します。

```python
@article.route('/<article_id>', methods=['GET'])
def get_article(article_id='1'):
    """
    記事のテンプレートを返す
    """
    article = ArticleManager().get_article(article_id)
    sidebar = SidebarManager()
    # 閲覧記録を保存する。
    VieLogsManager().insert(article_id, request)
    return render_template('article.html', title=article.title, article=article, sidebar=sidebar)
```

**ViewLogModel.py**

```python
import os
import boto3
from boto3.dynamodb.conditions import Attr, Key

from datetime import datetime, timedelta, timezone


class VieLogsManager:
    """
    ページビュー記録の操作
    """
    def __init__(self):
        # Initialize connection with database
        session = boto3.session.Session(
            region_name=os.environ['MY_REGION'], 
            aws_access_key_id=os.environ['MY_ACCESS_KEY_ID'], 
            aws_secret_access_key=os.environ['MY_SECRET_ACCESS_KEY']
        )

        dynamodb = session.resource('dynamodb')

        # Connect to db table
        self.table_name = 'page_view_logs'
        self.table = dynamodb.Table(self.table_name)
        self.JST = timezone(timedelta(hours=+9), 'JST')
    
    def insert(self, article_id, request):
        """
        閲覧履歴を記録する。
        """
        # if request.environ['REMOTE_ADDR'] is '127.0.0.1':
        #     # localでのテストは集計しない
        #     return

        http_connection = 'close'
        try:
            http_connection = request.environ['HTTP_CONNECTION']
        except Exception, e:
            print(e)

        item = {
            'article_id': article_id,
            'view_at': datetime.now(self.JST).strftime('%Y-%m-%d %H:%M:%s'), 
            'remote_addr': request.environ['REMOTE_ADDR'],
            'is_keep_alive': self.is_keep_alive(http_connection),
            'browser': self.accessed_browser(request.environ['HTTP_USER_AGENT']),
            'user_os': self.user_os(request.environ['HTTP_USER_AGENT'])
        }
        
        # 追加する
        responce = self.table.put_item(
            TableName=self.table_name,
            Item=item
        )
        return responce
```

クラス内のメソッドは順次解説します。

**解説**

`__init__(self)`では、クラスの呼び出し時にDynamoDBとの接続をします。
キー情報は、環境変数に入れてあります。

`put_item()`では、保存する項目をdictで渡せます。DynamoDbではプライマリーキーを必ず渡しましょう。


### コネクションの有無

```python
    @staticmethod
    def is_keep_alive(http_connection):
        return http_connection == 'keep-alive'
```

```
20180728追記：
request.environ['HTTP_CONNECTION']がローカルでは取得できましたが、Lamabda上ではKeyErrorとなっていしまいます。
現在、コネクションの有無は判定できません。
```

### ユーザーのブラウザを判定

`HTTP_USER_AGENT`から、ユーザーのブラウザを判定する関数です。
下記を参考にしました。

[UserAgentからOS/ブラウザなどの調べかたのまとめ](https://qiita.com/nightyknite/items/b2590a69f2e0135756dc)

keywordsに判定するkeyとブラウザをおきます。
異なるブラウザも同じキーワードが入っているため、判定する順序に気をつけてください。

※[python3.6からdictの順序が保たれます](http://www.freia.jp/taka/blog/python3-hash-randomie/index.html)。


```python
    @staticmethod
    def accessed_browser(http_user_agent):
        """
        return accessed browser
        """
        http_user_agent = http_user_agent.lower()
        keywords = {
            'trident': 'IE11',
            'edge': 'Edge',
            'chrome': 'Chrome', 
            'opr': 'Opera', 
            'firefox': 'Firefox',
            'safari': 'safari'
        }
        for key, val in keywords.items():
            if http_user_agent.find(key) > -1:
                return val
        return 'othres'
```

対象は、IE11, Edge, Chrome, Opera, Firefox, safariとその他otherとします。

### ユーザーのOSを判定

OSも同じく、`HTTP_USER_AGENT`から判定します。
[参考](https://qiita.com/nightyknite/items/b2590a69f2e0135756dc)も同じ。

```python
    @staticmethod
    def user_os(http_user_agent):
        """
        return user os
        """
        http_user_agent = http_user_agent.lower()

        keywords = {
            'nt 10.0': 'Windows 10',
            'mac': 'Mac', 
            'android': 'Android',
            'iphone': 'iPhone',
            'nt 6.1': 'Windows 7',
            'nt 5': 'Windows XP', 
            'linux': 'Linux'
        }
        for key, val in keywords.items():
            if http_user_agent.find(key) > -1:
                return val
        return 'othres'
```

OSでは、パソコンの他にスマホやタブレットも判定できるようです。
この関数では、Windows XP, 7, 10, Mac, Linux, iPhone, Androidを判定します。

## 結果

local環境で動かした結果です。

![table_page_view_logs](https://www.suzu6.net/images/posts/33/table_page_view_logs.png)

ChromeとFireFox、それからMacを認識できていますね。
その他の、ブラウザとOSは手元にないため、運用しつつテストしていこうと思います。


## IPアドレスの取り扱いについて

IPアドレスによって個人情報までばれてしまうと、心配になる方がいらっしゃるかと思います。
当サイトでは、IPアドレスを使って個人を特定することはありません。
あくまでも、統計解析の材料として扱います。

個人のIPアドレスで分かるのは、最寄りのルーター位置のみで、最大でも市区町村単位までです。
また、IPアドレスはリクエスト先や途中でも、常に公開されるものです。

> **IPアドレスから得られる情報**  
> IPアドレスの経路を確認した場合に、ルータのホスト名から位置を推定できる場合もあります。しかし、その場合であっても、追跡できるのは最寄りのルータまでとなり、そこから先の詳細な住所などはわかりません。
> 弊社では専任の調査員による位置情報調査を行っていますが、ルータ単位での位置判定は、最大で市区町村単位となっています。  
> 引用元：[IPアドレスから個人情報はどこまでわかる？](http://www.geolocation.co.jp/learn/dns/26.html)

ご自身のIPアドレスの情報は[IPアドレスから住所を検索](http://keiromichi.com/index.php)から確認できます。
私が試した結果は、位置情報は隣の市が表示されました。

それでも心配な方は、セキュリティソフトやファイヤーウォールの設定をしっかりと見直してください。

## おわりに

機能の構築と本記事の作成の中で、ウェブの解析ソフトが見ている情報や情報の扱いまで学ぶことが出来ました。
ネットワークの技術も、これを機に調べていこうと思います。

収集したデータを使った解析は、また次回行います。

最後までご覧いただき、ありがとうございます。

---

設計編はこちら
[リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-1.設計編](https://www.suzu6.net/posts/33)

---
本ブログの構成について

- [AWSで始めるサーバレスなブログサービス](https://www.suzu6.net/posts/2)
- [CroudFrontとAPI Gatewayで自作ブログサイトを改善しました](https://www.suzu6.net/posts/7)
- [[Python] Flask入門とサーバレスアーキテクチャ](https://www.suzu6.net/posts/6)

リクエスト情報から訪問者の情報を集めてみる[Python Flask + DynamoDB]-2.実装編


## この記事について

こんにちは、suzu6です。

以前、こちらでざっくりとご紹介した本ウェブサイトの構成を変更しました。

[AWSで始めるサーバレスなブログサービス](/article/2)

まだPV数もありませんが、すでに構成上の問題点が浮き彫りになったので、修正しました。

引き続き、AWS Lambda上にPython+Flaskを使ってサーバレスな構成で運用しています。

## 変更する前の構成

まずは、変更前のAWSの構造を見て下さい。

![変更前](/images/posts/2/blog_%E6%A7%8B%E6%88%90.svg)

LambdaにFlaskのアプリを置き、S3から画像やアイコンを直接取得する構成にしていました。

### 問題点１：Lambdaへのリクエスト数が多すぎ！

ひとつのLambdaの中に、アプリの処理だけでなくjsライブラリやCSSファイルも同梱して置いていました。

この場合、クライアント側でHTMLを読み込む時に何度もLambdaへリクエストをしているようです。まだPV数も自分で確認した100回程しかないのに、Lambdaへの13,847回もリクエストが飛んでいました。

Lambdaは計算時間だけでなく、リクエスト回数も従量制です。無料枠の１％ほどのリクエストですが、今後PV数が増えることを願って今のうちに対策を立てたいと思います。

### 問題点２：S３から直接取るのはどうなの？

API Gatewayにカスタムドメインを設定して、基本はLambdaで処理しています。画像やアイコンはS3に置いて、S3から直接取得するようにURLを記述していました。

一人で運用しているので、S3にファイルを置いてリンクを記事に貼り付けて。。。といった作業はまだ苦痛ではありません。

しかし、クロスドメインの問題があり、ブラウザによっては推奨されないようです。

[クロスドメイン (cross domain)とは](https://wa3.i-3-i.info/word15224.html)

## 解決策１：S3に静的ファイルを集めてCloudFrontを使おう！

Lambdaへのリクエスト数を減らすため、S3にjsライブラリやCSSファイルを置きました。

ついでに[CloudFront](https://aws.amazon.com/jp/cloudfront/)を使って高速化もしましょう！CloudFrontはコンテンツをキャッシュ化して、通信にかかるレイテンシ（遅延）を改善します。こちらも無料枠が50GBあるので早速利用します。

主にclassmethodさんのこちらの記事を参考にしています。

[CloudFront + S3 によるCDN (Cache Distribution パターン) 構築手順](https://dev.classmethod.jp/cloud/aws/cdn-with-cloudfront-and-s3/)

まず、ライブラリとCSSをS3に置きました。

CloudFrontの`Distribution`を作成して、`Origin Domain Name`からS3のbucketを選択します。

![cloudfront_s3](https://www.suzu6.net/images/posts/7/cloudfront_s3.png)

`Restrict Bucket Access`を「Yes」にしておきます。

不確かで申し訳ありませんが、`Origin Access Identity`を「Create a New Identity」、`Grant Read Permissions on Bucket`を「Yes, Update Bucket Policy」としていたと思います。

作成すると「*******.cloudfront.net」のURLができるので確認して下さい。

## 解決策２：API Gatewayに紐づけて、同じドメインで取得できるようにしよう！

Lambdaの関数はAPI Gatewayを通して公開しています。API GatewayはURLのリソースにAWSのサービスを紐づけることができます。

今回はFlaskのでの構成と同じく、「/static」以下にS3のbucketの内容を紐づけました。

![api_gateway_resource](https://www.suzu6.net/images/posts/7/api_gateway_resource.png)

「/」と「/{proxy+}」にLambda関数が紐づいています。

「/static」を作成してその下に「/{proxy+}」となるように、リソースを作成します。そして「/{proxy+}」にメソッドを作成します。メソッドは安全のためGETのみ許可しました。

セットアップでは、`統合タイプ`を「HTTPプロキシ」、`エンドポイントURL`に先ほど作ったCloudFrontのURLを入力します。
そのURLには「/{proxy}」をつけて下さい。

![api_gateway_method](https://www.suzu6.net/images/posts/7/api_gateway_method.png)

最後にアクションからAPIのデプロイをして完了です。

## 新しい構成

以上２点を改善した結果、新しい構成は以下のようになりました。

![新しい構成](https://www.suzu6.net/images/posts/7/blog-website-constitution.svg)

クロスドメインの問題も解消され、さらに静的ファイルのキャッシュ化とS3のセキュリティ面での強化もできました。
また、同一ドメインの同じリソース「/static」から取得できます。よって、ローカル環境のテストはstaticフォルダから、デプロイ先ではS3のbucketから同じURLで取得できます。

AWSのサービスを学んでいくと、便利で優れた構成が実現できると思います。
これからも、どんどん新しいことを吸収していきます！！

手順や構成面で誤りや不備がありましたら、footerのメールアドレスまでお知らせください。
コメント欄は今後実装する予定です。

---

AWS Lambdaなどサーバレス なシステム構成については、こちらの書籍がおすすめです。
<div class="babylink-box" style="overflow: hidden; font-size: small; zoom: 1; margin: 15px 0; text-align: left;"><div class="babylink-image" style="float: left; margin: 0px 15px 10px 0px; width: 75px; height: 75px; text-align: center;"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22/" rel="nofollow" target="_blank"><img style="border-top: medium none; border-right: medium none; border-bottom: medium none; border-left: medium none;" src="https://images-fe.ssl-images-amazon.com/images/I/51mWbC-xrZL._SL75_.jpg" width="59" height="75" /></a></div><div class="babylink-info" style="overflow: hidden; zoom: 1; line-height: 120%;"><div class="babylink-title" style="margin-bottom: 2px; line-height: 120%;"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22/" rel="nofollow" target="_blank">AWSによるサーバーレスアーキテクチャ</a></div><div class="babylink-manufacturer" style="margin-bottom: 5px;">Peter Sbarski</div></div><div class="booklink-footer" style="clear: left"></div></div>

最後までご覧いただきありがとうございました。

CroudFrontとAPI Gatewayで自作ブログサイトを改善しました


## この記事の目的

Python + FlaskのアプリをZappaを使ってAWS Lambdaにデプロイして、動作確認まで行います。
macでの環境の構築をメインに、丁寧に書いていきます。

## Zappaとは

GitHub:[Zappa](https://github.com/Miserlou/Zappa)

**Zappa**はコマンドラインでPythonのWSGIアプリケーションをデプロイできます。
AWSではLambdaに、また、他ののクラウドにも対応しています。

Lambdaでは直接コードを書く場合と、コードとライブラリをまとめたZIPファイルをアップロードしてデプロイします。
Zappaでは`virtualenv`の仮想環境をZIPファイルにまとめて、デプロイします。ZIPの作成も自動的に行なってくれるのでとても簡単です。

自分でZIPファイルにまとめてデプロイも可能です。
zipコマンドについては[こちら](https://www.suzu6.net/posts/63-zip-command)。

![デプロイの様子.gif](https://camo.githubusercontent.com/be05103c626a5afe18dc4b1208a4b465dbd9e731/687474703a2f2f692e696d6775722e636f6d2f6631504a7843512e676966)
デプロイの様子 : [Zappa](https://github.com/Miserlou/Zappa)より

必要な環境さえ整えれば、GIFの通り簡単にAWSにコードをデプロイすることができます。

日本語の記事では、[zappa で hello world するまで](https://qiita.com/satoshi_iwashita/items/505492193317819772c7)が参考になります。CentOS７で確認されていますので、Redhat系の方はこちらの手順で進めて見てください。公式からもリンクされており、公認みたいです。

公式を翻訳しているサイト[Zappa – サーバーレスPython](https://githubja.com/miserlou/zappa)もあります。応援しています‼️

## 環境

- macOS High Sierra
- Python3.6.5
- pyenv 1.2.3

## 流れ

1. pyenvとpyvirtualenvのインストール
2. Python3.6の準備
3. AWSのIAMの設定
4. デプロイする仮想環境の構築
5. アプリケーションの用意
6. Zappaのインストールとデプロイ

## 手順

### 1. pyenvとpyvirtualenvのインストール

まずは、仮想環境を用意しましょう。

macではパッケージマネージャーの`Home Brew`を使ってツールをインストールします。`Home Brew`がまだない方は、[こちら](https://brew.sh/index_ja)のスクリプトをコピーして、実行してください。


`Home Brew`をインストールできたら下記の手順でpyenvとpyvirtualenvのインストールを進めます。

```sh
$ brew install pyenv
$ brew update && brew upgrade pyenv
pyenv 1.2.1 -> 1.2.3

$ brew install pyenv-virtualenv
$ echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
$ exec $SHELL -l
```

`echo ...`でpyenvをログイン時に起動するよう書き込み、`exec ...`で即時起動しています。（たぶん。。。）

### 2. Python3.6の準備

続いて、macの環境をPython3.6にしておきましょう。
macにはデフォルトで2.7が入っています。変えたくない方や、他のバージョンを使っている方は飛ばしてください。

```sh
$ pyenv install 3.6.5
# 全体に反映
$ pyenv global 3.6.5
$ python --version
Python 3.6.5
```

python3.6が確認できたら、pipもアップグレードしておきます。`aws cli`をインストールするのに使います。

```sh
$ pip -V
pip 9.0.3 from /Users/{user}/.pyenv/versions/3.6.5/lib/python3.6/site-packages (python 3.6)
$ pip install -U pip
Successfully installed pip-10.0.1
```
### 3. AWSのIAMの設定

AWSにデプロイするためには、アクセスできるユーザとサービスの操作を許可するIAMの設定が必要です。

コンソールからデプロイ用のユーザを作成し、アクセスキーとシークレットキーを保管してください。
IAMの設定でユーザに操作の許可を与えてください。Lambda、S3、API GatewayのFullaccessは必要。その他、利用するサービスの権限を与えて下さい。

[Minimum AWS policies for example.](https://github.com/Miserlou/Zappa/issues/244)
こちらにpermission policieの例が載っています。


ターミナルに戻って、キーの設定を行います。
```sh
$ pip install awscli
$ aws configure
AWS Access Key ID [********************]:
AWS Secret Access Key [********************]:
Default region name [ap-northeast-1]:
Default output format [json]:
```
`aws configure`でアクセスキーなどを聞かれるので、打ち込んであげてください。　regionは東京にしました。

### 4. デプロイする仮想環境の構築

Lambdaには仮想環境ごとライブラリをまとめてデプロイします。
フォルダごとに仮想環境を用意しておくと何かと便利なので、ローカル環境を作成します。

```
$ pyenv virtualenv 3.6.5 bar
$ mkdir foo
$ cd foo
$ pyenv local bar
```
(bar) $ となっていれば成功。

`foo`というフォルダを用意して、そこにローカル環境`bar`を作成しています。
fooとローカル環境には適当な名前をつけて下さい。

> **※注意** 仮想環境の名前はZappaのプロジェクト名と同じものを使用しないで下さい。エラーが起こり得ます。

ここまでは、macで別のバージョンのpythonを使うとき便利です。

ローカル環境もpipを最新にしておきます。
```sh
$ pip install -U pip
Successfully installed pip-10.0.1
```

### 5. アプリケーションの用意

Flaskを使って`hello from Flask!`を返す簡単なアプリを作成します。

仮想環境を用意したディレクトリfooに、`app.py`を作成します。

foo/**app.py**
```python
from flask import Flask

app = Flask(__name__)

@app.route('/', methods=['GET', 'POST'])
def lambda_handler(event=None, context=None):

    return 'hello from Flask!'

if __name__ == '__main__':
    app.run()
```

fooに移動して、ライブラリをインストールして確かめて見ましょう。
```sh
$ cd foo
$ pip install flask
Successfully installed Flask-1.0.2 Jinja2-2.10 MarkupSafe-1.0 Werkzeug-0.14.1 click-6.7 itsdangerous-0.24
$ pip freeze
click==6.7
Flask==1.0.2
itsdangerous==0.24
Jinja2==2.10
MarkupSafe==1.0
Werkzeug==0.14.1

$ python app.py
 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: Do not use the development server in a production environment.
   Use a production WSGI server instead.
 * Debug mode: off
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
```

http://127.0.0.1:5000/をブラウザで開いて確認して見てください。
![hello_flask_local](https://s3-ap-northeast-1.amazonaws.com/webyasan-bucket/images/articles/4/hello_flask_local.png)

### 6. Zappaのインストールとデプロイ

とうとう、デプロイするところまできました。
まずは、Zappaをインストールして設定を行います。

```sh
$ pip install zappa
$ zappa init

███████╗ █████╗ ██████╗ ██████╗  █████╗
╚══███╔╝██╔══██╗██╔══██╗██╔══██╗██╔══██╗
  ███╔╝ ███████║██████╔╝██████╔╝███████║
 ███╔╝  ██╔══██║██╔═══╝ ██╔═══╝ ██╔══██║
███████╗██║  ██║██║     ██║     ██║  ██║
╚══════╝╚═╝  ╚═╝╚═╝     ╚═╝     ╚═╝  ╚═╝

Welcome to Zappa!
```
設定は全て`Enter`を押してデフォルトにすると以下の`zappa_settings.json`が作成されます。
フォルダ名がプロジェクト名になっています。
```
Okay, here's your zappa_settings.json:

{
    "dev": {
        "app_function": "app.app",
        "aws_region": "ap-northeast-1",
        "profile_name": "default",
        "project_name": "foo",
        "runtime": "python3.6",
        "s3_bucket": "zappa-9jex9436c"
    }
}
Does this look okay? (default 'y') [y/n]: y

$ ls
app.py                  zappa_settings.json
```

> **※注意(再掲)** 仮想環境の名前はZappaのプロジェクト名と同じものを使用しないで下さい。エラーが起こり得ます。

> 注意点として、実行ファイルの名前を合わせる必要があります。
**zappa_setting.json**の"app_function"を"{実行するファイル名}.app"として下さい。**hello.py**を実行する場合は次のようにします。`"app_function": "hello.app",`

デプロイします。
```sh
$ zappa deploy
Deployment complete!: https://81dc4kiste.execute-api.ap-northeast-1.amazonaws.com/dev
```
成功すると、API GatewayのURLが表示されます。
![hello_flask_lambda](https://s3-ap-northeast-1.amazonaws.com/webyasan-bucket/images/articles/4/hello_flask_lambda.png)

AWSのコンソールからLambdaを確認すると`foo-dev`という関数が作られていました。
![lambda](https://s3-ap-northeast-1.amazonaws.com/webyasan-bucket/images/articles/4/lambda.png)

> ※私の環境ではpermission policieにDynamoDBなども含めているので、Lambdaからアクセスできるようになっています。

アップデートもしてみましょう。
せっかくなので、URLで応答を変えるようにします。
`hello_name()`の関数を追加しました。

foo/**app.py**
```python
from flask import Flask

app = Flask(__name__)

@app.route('/', methods=['GET', 'POST'])
def lambda_handler(event=None, context=None):
    
    return 'hello from Flask!'

@app.route('/<name>', methods=['GET', 'POST'])
def hello_name(name):
    
    return 'hello ' + name

if __name__ == '__main__':
    app.run()
```

アップデートします。
```sh
$ zappa update
```
URLの末尾に文字を入れてください。

![update](https://s3-ap-northeast-1.amazonaws.com/webyasan-bucket/images/articles/4/update.png)

その他、ログを監視する`tail`や前のバージョンにロールバックする`rollback`など便利なコマンドがあります。
`zappa -h`で確認してください。


zappaの導入手順は以上となります。

## 同様のライブラリ

[Chalice](https://github.com/aws/chalice)

こちらはAWSのためのAmazon製のサーバレスマイクロフレームワーク。LambdaとAPI Gatewayのデプロイができるようです。

Zappaとの比較はこちらの記事が参考になりました。
[Python サーバーレスフレームワークの比較 - Zappa vs Chalice](https://qiita.com/massa142/items/c59275237979fd939791)

## 終わりに

Pythonでサーバレスな開発を行うなら、zappaがとても便利だと思います。
ただ、日本語の情報が少ないので、躓いたとき辛いです。。。
少しでも参考になれば、幸いです。

---

サーバレスアーキテクチャを勉強される方は、こちらの本がおすすめです。
<div class="amakuri-default-comment" style="text-align: left; line-height: 1.5em; margin-bottom: 10px; overflow:hidden; _zoom:1;"><div class="amakuri-default-comment-image" style="float: left; margin: 0 20px 0 0;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank"><img src="https://images-fe.ssl-images-amazon.com/images/I/51L3N%2B3pL1L._SL160_.jpg" width="128" height="160" alt="AWSによるサーバーレスアーキテクチャ" style="border: none"></a></div><div class="amakuri-default-comment-desc" style="overflow: hidden; _zoom:1;"><div class="amakuri-default-comment-title" style="margin-bottom: 0.5em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">AWSによるサーバーレスアーキテクチャ</a></div><div class="amakuri-default-comment-posted" style="margin-bottom: 0.5em; font-size: small;">Posted at 2018.12.21</div><div class="amakuri-default-comment-author">Peter Sbarski</div><div class="amakuri-default-comment-label" style="margin-bottom: 0.5em;">翔泳社</div><div class="amakuri-default-comment-link" style="margin-top: 1em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">Amazonで詳細を見る</a></div></div></div>

動画シェアサイトをAWS Lambda, S3を使って実際に構築する手順が載っています。
その中で、どのようにLambdaを構成したら良いか大変参考になりました。また、DynamoDBとAuth0も詳しく書かれています。

Zappaを使ってPythonのコードをAWS Lambdaにデプロイする



ご覧になっているサイトはサーバレスなブログサービスとなっています。

AWSのサービスを使ってサーバレスなウェブアプリケーションを作成方法を紹介していきます。

## この記事の要旨

この記事では、サーバレスアーキテクチャとはどんなものかAWSをベースにしてご紹介します。
そして、このブログサービスの構成の紹介をします。

## サーバレスアーキテクチャとは

サーバレスアーキテクチャとは、サーバの構築や管理が必要ないアプリケーションの実行環境です。  
サーバの構築や管理はクラウドの事業者に任せ、開発者はアプリケーションの開発に専念することが出来ます。

サーバーレスアーキテクチャ上のファンクションは、何らかのイベントをトリガーとして呼び出される。イベントごとに実行プロセスが起動し、ファンクションの終了とともにプロセスが終了します。
  
料金体系はプロセスの実行時間に対してのみ掛かるため、呼び出されない間は費用がかかりません。
また、自動的にスケーリングするため、アクセスの増減も柔軟に対応できます。
EC2などの常駐型のサーバに比べ、低コストでスケーラビリティに優れていまるようです。

ファンクションは、クラウドで提供されているその他のサービスと組み合わせてウェブアプリケーションを構築します。

AWSを見てみると、ファイル／データベースストレージ、メール配信、認証、IoTデバイスの管理や機械学習など様々なサービスがあります。それぞれ実装すると大変ですが、どれも簡単な設定で使えるようになっています。

この中から必要なサービスを選び、ファンクションで繋いで目的のサービスを構築していきましょう。

---
サーバレスアーキテクチャについてまとまっている記事
- [AWS サーバーレスコンピューティングとアプリケーション](https://aws.amazon.com/jp/serverless/)
- [BOXIL サーバーレスアーキテクチャとは | AWS Lambdaの機能・メリット・仮想サーバーとの違い](https://boxil.jp/mag/a3074/)

## AWS Lambda

AWSでのファンクションはLambdaです。イベントによって処理を実行するサービスであり、サーバレスの中核となります。

[Lambda 公式サイト](https://aws.amazon.com/jp/lambda/?sc_channel=PS&sc_campaign=acquisition_JP&sc_publisher=google&sc_medium=lambda_rlsa_b&sc_content=lambda_e&sc_detail=lambda%20aws&sc_category=lambda&sc_segment=269937092356&sc_matchtype=e&sc_country=JP&sc_brand=brand&ef_id=WtQ5@gAABZi3g2Lx:20180705082732:s)

Lambdaを使った例は、
- S3に画像をアップした時にサムネイル画像を作成する。
- APIサーバとして、クライアントから通信を受けたらJSONを返す。
- データベースに登録した値をみて、メールを通知する。
- 指定の時間が来たら、バックアップを作成する。
など、様々な用途で活躍します。

また、すでにEC2やELBで構築済みでも、一部の機能（クーロンのイベント処理）を取り出してLambdaで実装することもオススメです。
特定の時間だけ負荷が掛かるような処理を切り出して置くことでサーバの性能を小さくしたり、ロジックの切り分けができます。

Lambdaの利用パターンは、こちらの記事に詳しく載っています。

[Lambdaでのここまでの利用パターンまとめ](https://qiita.com/shot6/items/f368a187eae73fb527aa)


他のクラウドにあるLambdaと同等のサービスは、Microsft Azureの[Azure Functions](https://azure.microsoft.com/ja-jp/services/functions/)やGoogle Cloud Platformの[Cloud Functions](https://cloud.google.com/functions/docs/)があります。

## 今回利用したAWSのサービス

|サービス|概要|
|--|--|
|Lambda|イベントに対して実行される計算処理のサービス|
|DynamoDB|NoSQLのデータベースストレージ|
|S3|ファイルストレージ|
|API Gateway|AWSのサービスをRESTfulなAPIとして結びつける|

気をつける点はLambdaが並列分散する点です。LambdaとRDSを組み合わせて使うと、RDSのコネクションが増加してDBコネクションエラーになってしまいます。

参考：[Lambda+RDSはアンチパターン](https://qiita.com/teradonburi/items/86400ea82a65699672ad)

こちらに書かれているとおり、スケールアップの費用対効果が薄いようです。
そのため、データベースは分散データベースの運用とスケーリングに伴う管理作業をまかせることができるDynamoDBを利用した方が良いかと思います。

## サーバレスなブログサービス

前置きが長くなりました。。。

本ブログのシステムは、AWS上にこの図の構成でサーバレスアーキテクチャを実現しています。

![サーバレスなブログサービス](https://s3-ap-northeast-1.amazonaws.com/webyasan-bucket/images/articles/2/blog_%E6%A7%8B%E6%88%90.svg)

LambdaにPython＋[Flask](http://flask.pocoo.org/)（マイクロWebフレームワーク）で基本的なブログサービスの処理を書いています。

API GatewayにはRoute53で取得したドメインを割り当て、リクエストがあったらLambdaをキックするようにしています。

データベースはDynamoDBを利用して、記事の内容を保管します。NoSQLを初めて触ったので、RDBと特徴が全く違って苦労しましたが、なんとかブログの機能を持たせることができました。

画像などの静的ファイルはS3に置いて、Lambdaを呼びすぎないように分けています。ドメインが異なるため、CROSを有効に設定してあります。

現時点では、まだまだサービスを十分に活用できていません。

- S3から直接ファイルを取得しているところを、キャッシュサービスの`Cloud Front`を使って高速化する。
  - **2018年7月10日追記** [CloudFrontでのキャッシュ化を実装しました](https://www.suzu6.net/posts/7)
- Flaskに実装している管理者用の機能を分け、認証機能を`Cognito`に任せる。

など、運用しながら順次拡張していきたいと思っております。

## まとめ

サーバレスアーキテクチャとは
- サーバの構成や管理を（あまり）意識しなくてすみ、アプリの開発に専念できるできる
- スケーラビリティに優れている
- 利用した分だけ払う低コスト
- 部分的な置き換えも可能


サーバレスアーキテクチャを勉強される方は、こちらの本がおすすめです。
<div class="amakuri-default-comment" style="text-align: left; line-height: 1.5em; margin-bottom: 10px; overflow:hidden; _zoom:1;"><div class="amakuri-default-comment-image" style="float: left; margin: 0 20px 0 0;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank"><img src="https://images-fe.ssl-images-amazon.com/images/I/51L3N%2B3pL1L._SL160_.jpg" width="128" height="160" alt="AWSによるサーバーレスアーキテクチャ" style="border: none"></a></div><div class="amakuri-default-comment-desc" style="overflow: hidden; _zoom:1;"><div class="amakuri-default-comment-title" style="margin-bottom: 0.5em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">AWSによるサーバーレスアーキテクチャ</a></div><div class="amakuri-default-comment-posted" style="margin-bottom: 0.5em; font-size: small;">Posted at 2018.12.21</div><div class="amakuri-default-comment-author">Peter Sbarski</div><div class="amakuri-default-comment-label" style="margin-bottom: 0.5em;">翔泳社</div><div class="amakuri-default-comment-link" style="margin-top: 1em;"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4798155160/suzu60c-22" target="_blank">Amazonで詳細を見る</a></div></div></div>

動画シェアサイトをAWS Lambda, S3を使って実際に構築する手順が載っています。
その中で、どのようにLambdaを構成したら良いか大変参考になりました。また、DynamoDBとAuth0も詳しく書かれています。

最後まで読んでいただき、ありがとうございました。