JAWSDAYS2021に初参加しました

こんにちわ、krkettleです
2021 年 3 月 20 日(土)に開催された JAWS DAYS に(聴く側で)参加しました
その時の感想をダラダラと書きたいと思います

[:contents:]

参加したきっかけ

私は 2019 年に入社、9 月に配属されてから業務で AWS を触り出したので AWS 歴はちょうど 1 年半くらいですが、初めて JAWS のイベントに参加しました

そのきっかけは主に以下の 2 点ですね

• Twitter で「参加登録しました」ツイートが回ってきた
• 会社のプロジェクトでたまたま AWS 認定 12 冠という超人的な先輩とご一緒した

オンライン開催だったというのもイベント初心者としては
ハードルが下がり、参加しやすかったとい理由もあります

拝聴したセッション

土曜日だったこともあり、昼休憩を除いて 09:50 ~ フル参加しましたが
その中でも特に印象に残ってるセッションについて感想を綴ります
自分の業務的にサーバレス系(Lambda, ECS など)の話を重点的に聞きに行きました

AWS Lambda のテストで役立つ各種ツール

私も過去に簡単なサーバレスアプリを Serverless Framework で作ったことがあるのですが
その時に

• Lambda のテストってどうするんだろう？
• API Gateway 叩きに行くしかないのか？

とか思ってたので、まさに聞きたい内容で申込日から楽しみにしてました
聞いてみた感想は「めっちゃよかった」です

特によかったなと思うのは

• 各項目でメリット・デメリットやハマりポイントが紹介されていた
• Serverless Framework の便利なプラグインが紹介されていた

といったところですね
後述もしますが、AWS CDK が人気というのは聞いていたので試したいな〜と思うものの
TypeScript からまず勉強しないとな状態なので、もう一度しっかり Serverless Framework やろうかなと思いました

(資料はJAWS DAYS 2021 公式ページに公開されています！)

サーバーレスとコンテナを活用したアプリケーションの開発の今 〜クラスメソッド MAD の顧客は何を採用しているのか？〜

いつもお世話になってるクラスメソッドさんの濱田 孝治さんの発表です

AWS re:Invent で話題になった話から始まり
クラスメソッド MAD の案件概要も紹介してくれました

感想としては

• フロント React か！引き続き勉強していこう
• やはり CDK 来てるのか〜TypeScript 勉強しないとな〜
• CircleCI 使ったことないんだよね...やろうかな？
• Auth0 も聴くけど使ったことない...まずは Cognito からやろうかな...

といった感じでした

最後に「インフラとアプリの境目とかない」というメッセージがあり仰る通りだなと思いました。 まずは社会人 3 年目に向けての抱負にも書いたことを実行していくのみです(わっしょい！)

krkettle.hatenablog.com

(こちらも資料はJAWS DAYS 2021 公式ページに公開されています！)

Cognito+API Gateway+Lambda+S3 ではじめるサーバーレスアプリ構築 ~SIer 企業がはじめて挑戦してみた話~

サーバレスをやろうとしていたのですが、Cognito も勉強したいなと思っていたので
まさに！なセッションで期待大でした。内容も期待以上に良いセッションで目から鱗でした
(個人的には学生時代にやっていた AtCoder を久しぶりに見つけて熱かったです)

まず Lambda と ENI の話ですが、こちらは Lambda のコールドスタート問題で ENI が話題になっていたので、なんとなく知っていたのですが図にしてみると頭が整理できました

次に S3 の HTTPS アクセスの話ですが、私も過去に寮飯確認 Bot を作った時に直面しました
その時になんとなくの理解で終わっていたので、こちらも頭が整理できました

krkettle.hatenablog.com

Serverless Framework の負荷検証の話などにも触れられており
これからサーバレスアプリ開発をしようとしている身としては非常に参考になるセッションでした

(こちらも資料はJAWS DAYS 2021 公式ページに公開されています！)

全体を通して

今回は紹介しませんでしたが他にも素晴らしいセッションがいくつもありました
LT の「AWS IoT EduKit で遊ぼうぜ」とかも遊びたい！って素直に思いました

あとオープニング映像が凄すぎる！
初めて大きめの Tech イベントに参加しましたがライブみたいな感じでしたね(ライブもいったことないけど)

いつか登壇者側で参加したいですね(4 年目の目標にしようかな...)
定期開催の JAWS イベントにも機会を見つけて参加したいと思います

運営の方々、発表者の方々本当にありがとうございました。 また、当日発生した地震で被害に遭われた方々にお見舞いを申し上げます。

10分でVSCodeの開発環境を整える

こんにちわ、krkettleです
この記事では VSCode の開発環境を整える方法について紹介します

この記事を読んで分かること

• VSCode での Python の開発環境構築
• VSCode モジュールの追加方法
• Remote SSH の設定方法

※macOS で稼働確認をしています

前提条件

対象者

• エディタとして VSCode を使おうとしている人
• VSCode で Remote SSH を使おうとしている人
• SSH 接続先で vim/emacs 等 を使っているが、GUI で操作したいと思っている人

VSCode(Visual Studio Code) とは

• Microsoft が開発しているエディタ
• 無償で利用可能(公式サイトからダウンロード可能)
• Windows だけでなく、Linux, macOS で利用可能
• プラグインを入れることでカスタマイズが可能

VSCode を使うと何が嬉しいか

VSCode 以外にも以下のようなエディタがあります

• Atom
• Sublime Text
• Pycharm

上記のエディタを一通り使いましたが、VSCode の魅力と思うのは

• 無償で使える
• サクサク動く
• プラグインが豊富でカスタマイズしやすい
• Remote SSH が強い
• マルチカーソルなどの便利な機能が多い
  • 参考: VSCode のマルチカーソル練習帳

プラグインをインストールする

VSCode の魅力の一つであるプラグインのインストール方法を紹介します
方法は主に以下の２つです

• 画面上(GUI)でインストールする
• Code コマンド(CLI)でインストールする

今回は Code コマンドの方法を紹介します

Code コマンドの有効化

「Command + Shift + P」でコマンドパレットを起動し、
「Shell Command: Install 'code' command in PATH」をクリックします
(Shell Command くらいまで入力すれば出てきます)

※以降で紹介するプラグインを全てインストールする場合は次のコマンドを実行してください

code --install-extension pkief.material-icon-theme
code --install-extension coenraads.bracket-pair-colorizer
code --install-extension eamodio.gitlens
code --install-extension mhutchie.git-graph
code --install-extension ms-vscode-remote.remote-ssh
code --install-extension ms-vscode-remote.remote-containers

見た目系プラグイン

まずは見た目を整えるためのプラグインです

material-icon-theme

画面左に表示される Explorer のロゴをいい感じにするプラグインです

code --install-extension pkief.material-icon-theme

Bracket Pair Colorizer

対応する括弧をわかりやすく表示してくれるプラグインです

code --install-extension coenraads.bracket-pair-colorizer

開発系プラグイン

次は開発系のプラグインです
プログラミングをする上で必須とも言える Git のサポートプラグインや
SSH, Docker のサポートプラグインを紹介します

GitLens

Git のコミット履歴や、誰がいつコミットしたかが手軽に分かるようにするプラグインです

code --install-extension eamodio.gitlens

GitGraph

Git のコミットグラフが手軽に分かるようにするプラグインです

code --install-extension mhutchie.git-graph

Remote SSH

SSH 接続先のファイルを VSCode 上で修正できるプラグインです
以下の手順で Remote SSH が出来ます

1. プラグインをインストール
2. ~/.ssh/config を書く
3. SSH 接続する

プラグインをインストール

code --install-extension ms-vscode-remote.remote-ssh

~/.ssh/config を書く

こちらに関しては以下の記事を参照してください

krkettle.hatenablog.com

krkettle.hatenablog.com

SSH 接続する

以下の 2 つの方法があります

1. コマンドパレットから SSH 接続する
   • 「Command + Shift + P」でコマンドパレットを起動します
   • 「Remote-SSH: Connect to Host...」を検索してクリックします
2. 左下のボタンから SSH 接続する
   • 左下のボタンをクリックします
   • Remote-SSH: Connect to Host...」をクリックします

Remote Container

Docker コンテナ上のファイルを VSCode 上で修正できるプラグインです

code --install-extension ms-vscode-remote.remote-containers

こちらも RemoteSSH とほぼ同様でコマンドパレットまたは左下のボタンから
「Remote-Containers: Attach to Running Container...」をクリックします
Docker に関しては以下の記事を参照してください

krkettle.hatenablog.com

krkettle.hatenablog.com

VSCode をカスタマイズする(setting.json)

「Command + Shift + P」でコマンドパレットを起動し、
「Preferences: Open Settings (JSON)」を検索しクリックします

以下の内容は執筆時における筆者の settings.json なので、
適宜自分の好みに合わせて修正してください

{
  // workbench
  "workbench.startupEditor": "newUntitledFile",
  "workbench.colorTheme": "Monokai",
  "workbench.iconTheme": "material-icon-theme",

  // editor
  "editor.fontFamily": "Source Han Code JP",
  "editor.fontSize": 14,
  "editor.tabSize": 2,
  "editor.renderWhitespace": "all",
  "editor.suggestSelection": "first",
  "terminal.external.osxExec": "iTerm.app",
  "explorer.confirmDragAndDrop": false,

  // python
  "[python]": {
    "editor.tabSize": 4
  }

  // (以下、略)
}

内容を一部抜粋して紹介します
(settings.json で各項目にカーソルを合わせると内容が表示されます)

• "workbench.iconTheme": "material-icon-theme"
  • Explorer のアイコンの設定
  • 前項でインストールした material-icon-theme を設定
• "editor.fontFamily": "Source Han Code JP"
  • フォントの設定
  • 等幅フォントである「源ノ角ゴシック」に設定
  • githubからインストールできます
• "editor.renderWhitespace": "all"
  • スペースを薄く表示する設定
  • markdown で改行忘れが減った気がする
• "terminal.external.osxExec": "iTerm.app"
  • ターミナルを iTerm にする
  • ターミナルは「Commanda + J」で開く・閉じることができる

まとめ

この記事では VSCode の魅力的な特徴を具体的なプラグインと共に紹介しました

10 分で入門する SSH(中級編)

こんにちわ、krkettleです
この記事では多段 SSH、ポートフォワードなどの SSH の中級者向けの内容について紹介します

前提条件

• macOS 、OpenSSH(8.1p1)で稼働確認をしています
• キーペアは ECDSA を利用して作成しています(鍵のパスを適宜読み変えてください)
• SSH で使われている技術(公開鍵認証・電子署名など)は説明しません
  • こちらについては以下の記事をご参照下さい krkettle.hatenablog.com
• キーペア作成やワンライナーでの SSH 接続は説明しません
  • こちらについては以下の記事をご参照下さい krkettle.hatenablog.com

プロキシを経由する

社内ルール等でプロキシを経由する必要がある場合は以下のように設定します
※Linux や Windows では設定が異なる場合があります

認証がない場合

Host remote
    (中略)
    ProxyCommand nc -X connect -x [proxy-ip]:[proxy-port] %h %p

• proxy-ip: プロキシの IP アドレス
• proxy-port: プロキシのポート番号

認証がある場合

Host remote
    (中略)
    ProxyCommand env CONNECT_USER=[proxy-user] CONNECT_PASSWORD=[proxy-pass] connect -H [proxy-ip]:[proxy-port] %h %p

• proxy-user: プロキシ認証のユーザ名
• proxy-pass: プロキシ認証のパスワード

多段 SSH

SSH 接続先で直接対象のサーバに接続するのではなく
踏み台サーバを経由することがあると思います

ローカル → 踏み台 → 目的のサーバ

ローカル → 踏み台 → 目的のサーバで 2 回 SSH コマンドを打つことなく
1 回の ssh コマンドでローカルから目的のサーバに接続する設定をします

Host bastion
    (略)

Host remote
    (中略)
    ProxyCommand ssh -CW %h:%p bastion

# 一回のコマンドでOK
ssh remote

言われてみれば当然ですが、踏み台サーバに秘密鍵をおく必要があります
ただ、踏み台サーバに重要なデータ(秘密鍵など)を置いておくのは好ましくないです
これはssh-agentを利用することで回避可能です

ssh-agent

ssh-agent を使うと以下のメリットがあります

• パスフレーズの入力回数を減らすことができる
• 認証情報を接続先に引き継ぐことができる (踏み台に秘密鍵情報をおく必要がない)

ssh-agent 実行の流れ

ssh-agent を起動する

eval `ssh-agent`

ssh-agent に秘密鍵を登録する

ssh-add -K ~/.ssh/id_ecdsa
Enter passphrase for ~/.ssh/id_ecdsa: # パスワードを入力してください

ssh-agent を用いて SSH 接続をする

# remote-user: アクセス先のユーザ名
# server-ip: アクセス先の(グローバル)IPアドレス
# -A: 認証情報の転送機能を有効化
ssh -A [remote-user]@[remote-ip]

ssh-agent を終了する

# ※SSH接続が終わった後に実行
eval `ssh-agent -k`

~/.ssh/config で 転送機能を有効化

~/.ssh/config でForwardAgentを設定しておけば
転送機能の引数(-A)を省略できます

Host remote
    (中略)
    FowardAgent yes

ssh remote

ssh-agent を自動終了する

ssh-agent を利用した後に毎回明示的に終了するのは面倒ですが
~/.zlogout に記述しておくことで、これを回避することができます

echo "$(which ssh-agent) -k" >> ~/.zlogout

ssh ポートフォワーディング

SSH 接続先で開いているポートをローカルで開きたい場合があります
Juypter Notebookを簡単な例にとってみましょう

Jupyter Notebook の具体例

Jupyter Notebook はブラウザで Python などのプログラムを実行したり、
分析結果を可視化できるツールで、以下のような手順で利用します

1. Jupyter Notebook を起動する
2. ブラウザを起動し、localhost の指定のポート番号にアクセスする

しかし、SSH 接続先で Jupyter Notebook を起動した場合はどうでしょうか
こんな時に役立つ機能が ssh ポートフォワーディングです

ssh ポートフォワーディングとは

ssh ポートフォワーディングには 2 種類存在します

• ローカルフォワード
  • リモートから(認証なしで)アクセスできる環境に、ローカルからアクセスする
• リモートフォワード
  • ローカルから(認証なしで)アクセスできる環境に、リモートからアクセスする

今回はローカルフォワードについてのみ設定方法を紹介します

ローカルフォワード

ローカルフォワードの流れは以下の通りです

ローカルフォワード設定をして SSH 接続する

# local-port: ローカルからアクセスするポート番号
# target-ip: 目的サーバのIPアドレス or ドメイン名
# target-port: 目的サーバのポート番号
ssh -L [local-port]:[target-ip]:[target-port] [remote-user]@[remote-ip]

ローカルのポートにアクセスする
(Chrome などのブラウザからでも、ターミナルから curl でも OK)

SSHポートフォワーディング

ここで注意事項があります
リモートマシン(remote)と目的のサーバ(target)は必ずしも別である必要はありません
(remote と target が同じ場合はtarget-ipの部分にlocalhostを設定すれば OK です)

~/.ssh/config で ローカルフォワードを有効化

~/.ssh/config でLocalForwardを設定しておけば
ローカルフォワードの引数(-L)を省略できます
※LocalForward は複数設定できるため、複数組のポートに対して設定可能です

Host remote
    (中略)
    LocalForward 8080 localhost:8888

ssh remote

上記の例では、ローカルの 8080 番ポートにアクセスすることで、 リモートマシン(remote)の 8888 番ポートにアクセスできます

具体例

これまでの内容を元に~/.ssh/config の具体例を紹介します
構成図と各種設定は以下の通りです

• ユーザ名: sample-user
• 秘密鍵のパス: ~/.ssh/id_ecdsa
• SSH 用ポート番号: 50022

具体例の全体構成図

ServerAliveInterval 60

Host bastion
    HostName bastion-ip
    User sample-user
    Port 50022
    ProxyCommand env CONNECT_USER=sample-user CONNECT_PASSWORD=password connect -H proxy-ip:proxy-port %h %p
    ForwardAgent yes

Host remote
    HostName remote-ip
    User sample-user
    Port 50022
    ProxyCommand ssh -CW %h:%p bastion
    LocalForwad 8080 localhost:8888

※今回の例では踏み台 - リモートマシン間が SSH 接続の必要があるため、 LocalForawrd では remote 内で localhost を利用しました

echo "$(which ssh-agent) -k" >> ~/.zlogout
eval `ssh-agent`
ssh-add -K ~/.ssh/id_ecdsa
ssh remote

10 分で入門する SSH(初級編)

こんにちわ、krkettleです
AWS などを利用する上で利用する機会の多い SSH をサクッと紹介していきます
※この記事では OpenSSH について紹介します

この記事を読んで分かること

• SSH アクセスの方法が分かる
• キーペア(公開鍵・秘密鍵)の作成方法が分かる
• SSH の設定ファイル(~/.ssh/config)の基本的な使い方が分かる

前提条件

対象者

• SSH を使った事がなく、これから使おうと思っている方
• SSH の細かい仕組みを知る前にまずは使えるようになりたい方
• Mac 利用者(稼働確認を macOS でしています)

この記事で紹介しないこと

• SSH サーバ側の説明や設定方法
• OpenSSH 以外の SSH クライアントについて(PuTTY, TeraTerm など)
• ssh-agentや~/.ssh/configの細かいオプションについて

SSH の仕組みで最低限抑えておくべき内容に関しては以下の記事をご覧下さい

krkettle.hatenablog.com

キーペアの作成

※既にキーペア(一組の公開鍵と秘密鍵)を作成している場合はスキップしてください

mkdir ~/.ssh # .sshディレクトリを作成する
chmod 700 ~/.ssh #　パーミッションを変更する

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Enter file in which to save the key:        # 作成したキーをどこに保存する？(デフォルトは$HOME/.ssh/id_rsa)
Enter passphrase (empty for no passphrase): # パスワードは何にする？(デフォルトはパスワード無し)
Enter same passphrase again:                # パスワードもう一回入力してね

デフォルトでは$HOME/.ssh 下に以下の 2 つのファイルが作成されます

• id_rsa: 秘密鍵(絶対に公開・流出させてはいけない)
• id_rsa.pub: 公開鍵(他人に公開して問題ない)

また、id_rsa は自分でも修正することが内容にパーミッションを変更しておきます

chmod 400 ~/.ssh/id_rsa

ssh-rsa が非推奨に

OpenSSH 8.3のリリースノートでは 5 万ドル以内 SHA-1 アルゴリズムに対して攻撃可能なため、ssh-rsa を近い将来デフォルトで 無効にするとあります
(OpenSSH 7.2 以降の RSA であればデフォルトで SHA-2 が使われているようです)

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

そのため、RSA の代わりに ECDSA を選択しても良いでしょう
※一部のレガシーシステムでは ECDSA をサポートしていない場合もあるので要確認

ssh-keygen -t ecdsa -b 521 -C "your_email@example.com"
Enter file in which to save the key:        # 作成したキーをどこに保存する？(デフォルトは$HOME/.ssh/id_ecdsa)
Enter passphrase (empty for no passphrase): # パスワードは何にする？(デフォルトはパスワード無し)
Enter same passphrase again:                # パスワードもう一回入力してね

※以降の章では ECDSA を用いた場合を想定して紹介します

アクセス先への公開鍵登録

アクセス先の~/.ssh/authorized_keys にアクセス元の公開鍵を追記する必要があります
※AWS などのパブリッククラウドではサーバ(AWS では EC2)作成時に公開鍵を登録することができます

ssh-copy-id は使わない方が良さそう

ssh-copy-idというコマンドを使うとリモートマシンに公開鍵を登録出来ます

# remote-user: アクセス先のユーザ名
# server-ip: アクセス先の(グローバル)IPアドレス
ssh-copy-id -i id_ecdsa.pub [remote-user]@[server-ip]

しかし、ssh-copy-idではパスワード認証を利用します

ssh-copy-id is a script that uses ssh(1) to log into a remote machine (presumably using a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities).

そのため、SSH 接続先のサーバ側でパスワード認証を有効にする必要がありますが、
SSH 接続において原則パスワード認証は使わない方がよく、公開鍵認証を使うべきです
(※AWS の EC2 ではデフォルトでパスワード認証が禁止されています)

SSH 接続

※SSH サーバ側は以下の条件を満たしているとします

• SSH クライアントから SSH アクセス可能な状態(IP 制限等はなし)
• 22 番ポートを開放

秘密鍵のパスを指定する

SSH 接続をする上で以下の二つを用いて公開鍵認証を行います

• 接続元の秘密鍵
• 接続先の公開鍵

そのため、SSH 接続する際には秘密鍵のパスを指定する必要があります
ただし、以下のパスであれば指定する必要はありません

• ~/.ssh/id_rsa
• ~/.ssh/id_dsa
• ~/.ssh/id_ecdsa
• ~/.ssh/id_ed25519

# -i: 秘密鍵のパスを指定する
ssh -i ~/.ssh/private_key [remote-user]@[server-ip]

アクセスするポート番号を変更する

SSH には 22 番ポートがよく使われます(Well-known Ports)
しかし、セキュリティ的には比較的攻撃されやすいことになるので
SSH 接続に使うポートをサーバ側で変更していることがあります
そのため、クライアント側でも接続先のポートを変更できます

# -p: ポート番号を指定
ssh -p 50022 [remote-user]@[server-ip]

自動切断されないようにする

SSH 接続したまま、しばらく操作しないと接続が切断されます
これを防ぐために一定時間おきに接続先に応答確認を送ります

# -o: 各種オプションを指定
ssh -o ServerAliveInterval=60 [remote-user]@[server-ip]

~/.ssh/config を設定する

引数が多くなってくると毎回コマンドを長々と打つのは面倒ですが
SSH 用の設定ファイル(~/.ssh/config)を作っておけばコマンドを省略できます

Host remote
    HostName remote-ip
    User remote-user
    Port 50022
    IdentityFile ~/.ssh/id_ecdsa
    ServerAliveInterval 60

※remote は任意の名前に変更可能

ssh remote

まとめ

この記事ではキーペアの作成から基本的な SSH 接続の方法を確認しました
再掲ですが、公開鍵認証や電子署名等を確認したい方は以下の記事をご覧ください
krkettle.hatenablog.com

AWS でサーバレスな寮飯確認 Bot を作った話

こんにちわ、krkettleです
今回は AWS で寮飯確認 Bot を作った、そしてサポートを終了した話を書きたいと思います

背景

私は社員寮在住なのですが、ありがたいことに
夕食は寮で提供されます(代金は取られますが良心的だと思います)
ある日の夜、同期と寮食を食べようとした時に同期がポツリ

「うわー、今日の夕食カレーか！昼に食べちゃったよ」

寮では食堂の掲示板にその週の献立が掲示されるのですが
毎週献立を撮っておくのは面倒なものです...

そこで、当時私が AWS ソリューションアーキテクトの資格を取ろうと
思っていたこともあり、練習も兼ねて寮生の悩みを解決することにしました
(AWS SAA に合格できました！)

krkettle.hatenablog.com

AWS 構成

家賃が安いが売りの社員寮に住む寮生から、なけなしのお金を取るわけにはいきません
そこで以下のコンセプトで構成を考えることにしました

• 出来る限り安く(出来れば無料で)
• 運用コストをできる限り抑える
• 最小構成でまず動くものを

全体構成図は以下の通りです

AWS全体構成図

寮飯確認 Bot のフロー

1. 利用者は事前に LINE の寮飯確認 Bot チャンネルに登録
2. 運営者が寮飯の献立画像を撮影し S3 にアップロード
3. 寮食が提供される曜日の 11:30 に献立画像を寮飯確認 Bot に送信

画像アップロード

当初の予定では下図のように S3 への画像アップロードもシステム化する予定でした
(覚えたての React と S3 の静的ホスティングを使って Web アプリっぽく)

当初のAWS全体構成図

しかし、コア要素でないところに時間を掛けたくないのと
「最小構成でまず動くものを」というコンセプトから外れるため後回しにして
まずは手動で AWS コンソールから運営者(私のみ)がアップロードすることにしました

メッセージ送信

今回は無料のLINE Messaging APIを利用しました
この API では Push/Reply が可能ですが、今回は Push(Bot 側から送信する)だけを採用しました
その理由は以下の 2 点です

• 無料枠では送信可能なメッセージ数が固定なので、無駄な返信で消費しないようにするため
• 返信のたびに Lambda が起動するとお金がかかってしまうため

CloudWatch Eventsを使って指定の時間にLambdaが起動します
Lambda は S3 にアップロードした画像を Messaging API 経由で寮飯確認 Bot チャンネルに送信します

認証情報の管理

LINE Messaging API ではアクセストークンを発行する必要があるため
認証情報の管理が必須になりますが、AWS では認証情報の管理として以下の２つが有名です

• AWS Systems Magnager パラメータストア
• AWS Secret Manger

全体構成図でも書いているように、選んだのはパラメータストアです
理由は機能・非機能的に問題がなく無料だからです

両者の比較は以下の記事が参考になりました
参考: AWS の Parameter Store と Secrets Manager、結局どちらを使えばいいのか？比較

監視・通知

寮生に閉じられた完全無料なシステムとはいえ、
「ダウンしたら利用者から連絡がくるまで放置」というのは忍びないので
CloudWatch, Chatbotで監視・通知機能をつけました
仕組みは単純で Lambda で例外が発生したら管理者の Slack に通知します

S3 の署名付き URL でハマる

AWS は非常に使いやすくドキュメントも豊富なので
設計を含め全部で 3 時間ほどで最低限の機能が動くところまで出来ました
ただ S3 の署名付き URLで少しハマりました

なぜ署名付き URL を使ったのか

理由としては以下の通りです

• アップロード画像に有効期限をつけたかった
  • 献立は毎週変わるので古い画像はアクセスされないようにしたかった
• S3 バケットを非公開にしたかった
  • 誤って S3 から直接画像をダウンロードされないようにするため
  • 今から考えるとそれほど必要なかったかも
• (AWS SAA の試験対策時に知って使ってみたかったから)

発行者の認証情報に応じて署名付き URL の長さが変わる

今回署名付き URL は IAM ロールを付与した Lambda で発行しました
しかし以下の参考記事にある通り、IAM ロールを用いて署名付き URL を発行する場合
一時的な認証情報を用いるため、その情報を URL に含める必要があります
そのため、IAM ユーザを用いる場合よりも IAM ロールを用いる場合は URL が長くなります

署名付き URL が長いと何が問題なのか

通常であれば URL が長いのはそれほど問題にはならないはず(?)
しかし今回はLINE Messaging API の仕様に落とし穴がありました...

Image URL (Max character limit: 1000)

URL の最大長が1000に設定されていたんですね
(私の使い方がイレギュラーだと思うので、この仕様が悪いわけではないと思います)
これが原因となり Lambda でメッセージ通知時に例外が発生していました

どう解決したか

スマートなやり方ではないと思うのですが
Bitly APIを利用して署名付き URL の短縮 URL を発行して回避しました

今考えると

• そこまでして署名付き URL を使う必要はなかった
• 公開用の S3 バケットを用意して削除イベントを作るでもよかった
• 使ったことない技術使ってみたい気持ちが先行した感がある

本番環境と同じ環境で行うテストが大事

このハマり点のタチの悪いところはLambda で実行してみて初めて気づくという点です
自動テスト、CI/CD の設定は全く出来ていなかったので、ソースコードのチェックには
実行環境をローカルに Docker 環境で作って検証していました

krkettle.hatenablog.com

しかしローカル環境では IAM ユーザの認証情報を使用していため正常終了していました
よく言われることですが、本番環境とテスト環境は同じにしておくことが大事だなと実感しました

サービス開始、そしてサービス終了まで

晴れてサービス開始となりましたが、その数ヶ月後に終わりを迎えることとなりました

サービス開始

ハマりポイントはあったものの、AWS 様様で最低限動くサービスがサクッと完成しました

寮生の同期何人かに寮飯確認 Bot のアカウントを伝え利用してもらいました
「こんなの個人で作れるんだ」「すごいね！」という感想が嬉しかったです

拡張を考える

運用しているうちに利用者の同期からこんなコメントが

• 画像だけだとつまらないから、何か追加で配信してよ
• 献立の画像は 1 週間分の物が送られてくるけど、その日の分だけ切り出してよ

完全無料のアプリとはいえ、ありがたいご意見には応えたくなります

文章も送ってみる

1 つ目の要望は簡単に対応できました
今まで画像しか配信していませんでしたが当然文章も配信可能です
毎日労いの言葉を添えるようにアップデートしました

献立の画像を切り出す

2 つ目の要求には画像処理が必要になります
学部時代の記憶を掘り起こしOpenCVなどでゴニョゴニョしましたが
実用に耐えうるものは出来ず、これに関しては一旦断念しました

自動化したい気持ちが強くなる

ソースコードを変更するたびに zip で固めて Lambda にアップロードするのは
流石に面倒だし署名付き URL の件もあったので自動化したい気持ちが強くなりました

丁度その頃 Udemy でAWS Code シリーズの講座を受講していたこともあり
Serverless Framework, AWS CDKあたりで CI/CD 環境作ろうと思っていました

サービス終了

思い描いていた拡張は叶うことなく、サービスは突如終わりを迎えます
理由としては「業務が忙しくなってきた」という月並みな言い訳もありますが
最大の理由は献立撮影＆S3 へのアップロードが面倒だったからです

技術に関することであればたとえ無料でも頑張れたのですが、
「毎週写真を撮って、S3 に上げる」という単純な作業が面倒になってしまったのです...

怠惰

これが最大の理由となり、サービスは数ヶ月の歴史に幕を閉じました

サービスを振り返って

終焉はあっけなかったですが結果ローコスト・ハイリターンだったと思います

よかった点

1. AWS の使った開発ができた
2. AWS 利用料が無料枠の範囲内でサービスを運営できた
3. 同期の何人かに実際にサービスを利用してもらえた

反省点

1. モチベーションの維持方法を考えるべきだった
   • 募金という形式でも利用料を取れば義務感が生じたかも
   • 一人で運営せずに運営側に仲間を巻き込めばサボらなかったかも
2. せめて自動テストまではやり切りたかった
   • Github Actions, AWS Code Pipelineの Hello World くらいはやったので次の開発では真っ先に取り組みたい

プロダクト開発してみると色々学べるのは分かってるんだけど、最初の一歩がなかなか出んのよね...

10 分で入門する SSH(概念編)

AWS などを使う上で利用する機会の多い SSH の概要を暗号技術の基礎を踏まえて紹介します

この記事を読んで分かること

• SSH はどういう時に使うのか分かる
• 公開鍵暗号の概要が分かる
• 共通鍵暗号、公開鍵暗号の違いが分かる
• SSH による暗号化通信までのステップが分かる

前提条件

対象者

• SSH を使った事がなく、これから使おうと思っている方
• SSH を使っているけど、最低限の仕組みは抑えておきたい方

この記事で紹介しないこと

• 具体的な SSH のコマンドや設定
• SSH を使う上で最低限必要なものではないと筆者が判断したもの

SSH についての基礎知識

以下の 2 点についてこの章で紹介します

• SSH とは何か？
• SSH を使うと何が嬉しいの？

SSH とは何か？

ざっくり言うとリモートマシンに安全にアクセスする仕組みです
暗号技術を活用して通信を暗号化し、安全に通信を行うために利用できます

SSH を使うと何が嬉しいの？

そのままですがリモートマシンに安全に接続できることが利点です
ただ、分かりにくいので具体例を挙げて説明してみます

A さんは自宅のノート PC から大学の研究室にあるサーバにアクセスしたいと考えています
しかし、大事な研究情報を悪意のある人に盗聴されてしまう可能性があります
そこで SSH を利用する事で盗聴の心配なく、安全に通信ができました

(最近の研究室はサーバじゃなくてクラウドのインスタンスとかなのかな...?)

どうやって安全に通信するの？

安全に通信を行うには暗号化通信を行います

• 暗号化: 通信内容を他人にわからないように加工します
• 復号: 暗号化された通信内容を元の状態に戻します
  • ※復号であり、復号化ではないので注意

具体例としてシーザー暗号を挙げてみます
シーザ暗号とは「文字を辞書順で N 文字分ずらす」暗号です

N = 2 の時 A → C, B → D になります
事前に N の値を通信相手と合意しておけば暗号化通信が可能です
「N」を暗号における鍵、暗号化される前のデータを平文(ひらぶん)と呼ぶ

N = 2のシーザー暗号

※シーザ暗号は簡単な暗号の一例として挙げましたが
SSH に使われている訳ではないのでご注意ください

認証ってどうするの？

暗号化通信によって盗聴を防ぐことは分かりましたが
どうやって正規の通信相手かを見分けるのでしょうか → この答えが認証です

通信相手が誰であるかを確認することを認証と言います
(ちなみによく混同されますが、認証と認可は異なります)

参考: よくわかる認証と認可

SSH にはどんな認証の種類があるの？

SSH では主に以下の 2 つの認証があります

• パスワード認証方式
• 公開鍵認証方式

パスワード認証方式は、リモートマシンのユーザ名とパスワードによる認証です
ただし後述の公開鍵認証方式と比べるとセキュリティが低いので注意が必要です

公開鍵暗号・電子署名

この章では公開鍵暗号・電子署名について紹介します
どちらも後述の公開鍵・秘密鍵を用いますが、暗号と署名は別物なので注意してください

参考: 「電子署名=『秘密鍵で暗号化』」という良くある誤解の話

公開鍵暗号

公開鍵暗号とは公開鍵・秘密鍵を用いた暗号方式のことです
公開鍵と秘密鍵は対になっており、二つ合わせてキーペアと呼ばれます

• 公開鍵
  • 他人に公開して良い鍵
  • GitHub 等を利用する際にも登録することがあります
  • 暗号化に用いる
• 秘密鍵
  • 絶対に公開してはいけない鍵です
  • 盗まれると「なりすまし」されてしまう危険があります
  • 復号に用いる
• 暗号化＆復号
  • 送り主は受け取り主の公開鍵で暗号化し、受け取り主は自分の秘密鍵で復号する
  • 公開鍵を使って誰でも暗号化できる
  • 復号できるのは秘密鍵を持つ本人だけ

公開鍵暗号

電子署名

データに署名する事で、本人確認やデータの改竄検出を行う事が出来ます
署名には秘密鍵を、署名の検証には公開鍵を使います

ポイントは以下の通りです

• 秘密鍵を持つ本人しか署名が出来ない
• 署名の検証は公開鍵を使うため誰でも出来る
• 署名対象のデータをハッシュ化した値(ハッシュ値)から電子署名を作成する
• ※署名と共に元のデータが送られるため、ハッシュ化の方法が合意されていればハッシュ値は計算できる(検証できる)

電子署名を用いた認証を公開鍵認証と呼びます

参考: 暗号学的ハッシュ関数(Cryptographic Hash Function)

電子署名

共通鍵暗号との違い

前述のシーザ暗号のように暗号化・復号に同じ鍵を使う暗号方式のことを共通鍵暗号と呼びます
(これに対して公開鍵暗号のことを非対称鍵暗号とも呼んだりします)

共通鍵暗号と公開鍵暗号の違いは以下の通りです

	共通鍵暗号	公開鍵暗号
認証範囲	真正性	真正性・否認防止
鍵管理	大変	容易
暗号化速度	早い	遅い

認証範囲

公開鍵認証は前述の通り電子署名を利用します 共通鍵暗号でもメッセージ認証コード(MAC)などの認証方式がありますが
公開鍵認証と異なり署名と検証の鍵が一緒なので否認の防止や第三者証明が出来ません

鍵管理

鍵の管理ですが共通鍵暗号では 2 つの不便さがあります

1. 鍵の交換方法がない
   • 公開鍵暗号であれば公開鍵を渡す際に盗まれたとしても問題ありません
   • 共通鍵は盗まれないように渡す必要があります
2. 管理する鍵の数が増える
   • 鍵は通信したい相手の数だけ持つ必要があります
   • n 人の間で各々通信したい場合は n(n-1)/2 個の鍵が必要になります

暗号化速度

一般に共通鍵暗号の方が公開鍵暗号よりも高速です
そのため SSH では 2 つを組み合わせたハイブリッド暗号を用います

• 公開鍵暗号: 鍵交換・認証に使う
• 共有鍵: 暗号化＆復号・メッセージ認証に使う

公開鍵認証を活用した暗号化通信

公開鍵認証では通常以下のステップで暗号化が行われます

1. 鍵交換
2. 認証
3. 暗号化通信

鍵交換

キーペアを使い、２者間で秘密裏に情報を共有できる方式です
これを利用して暗号化通信に使う共有鍵を交換します

※以下の参考記事が非常に分かりやすいので参照することをオススメします

• 参考: 2 つの公開鍵暗号(公開鍵暗号の基礎知識)
• 参考: SSH のハイブリッド暗号に関する良くある誤解の話

認証

アクセス元は「接続先が本当に意図している相手か」を公開鍵認証で確認します
(具体的には接続先の署名を、接続先の公開鍵を用いて検証します)

暗号化通信

鍵交換した共有鍵を用いて暗号化通信を行います
鍵交換〜認証に用いたキーペアは原則使い回しますが
暗号化通信に用いた共有鍵は使い捨てで問題ありません

まとめ

この記事では以下の 4 つについて確認しました

• SSH はどういう時に使うのか分かる
• 公開鍵暗号の概要が分かる
• 共通鍵暗号、公開鍵暗号の違いが分かる
• SSH による暗号化通信までのステップが分かる

SSH を使うだけであれば以下の点だけ意識しておけば良いでしょう

• 秘密鍵は絶対に誰にも渡さない
• 公開鍵は他の場所に置いても問題はない

参考書籍

• 暗号技術入門 第 3 版　秘密の国のアリス

AWS ソリューションアーキテクトアソシエイト(SAA)合格体験記

こんにちわ、krkettleです
2020 年 12 月 AWS ソリューションアーキテクトアソシエイト(SAA)に合格しました
行った対策、申込〜試験当日、これから勉強する方へのオススメの勉強法について書きたいと思います

学習期間と行った対策

• 学習期間: 約 3 ヶ月
• 行った対策
  • AWS 公式資料や動画学習サイトを活用する
  • 実際に AWS サービスを触ってみる

学習期間: 約 3 ヶ月

私の場合は以下の理由(言い訳)から 3 ヶ月ほどかかりました

• ネットワーク、DB、DNS などの IT 基礎知識が不足していた
• 業務が忙しい時期だったため、平日に勉強時間を思うように確保できなかった
• 周辺知識を調べすぎた

IT 基礎知識が既にあったり、短期集中で時間を確保できる方であれば
2 週間 ~ 1 ヶ月ほどで合格することも可能だと思います

行った対策

行った対策は主に以下の通りです

• AWS 公式資料を読む
• AWS サービスを実際に使ってみる
• Udemyで対策講座を受講する
• 疑問に思った内容を適宜調べて理解を深める

AWS 公式資料を読む

基本的に困ったときはAWS 公式ドキュメントをみるのが一番です
ただ、日本語の翻訳が一部おかしい時もあるので可能であれば原文(英語)で読むのがより良いと思います

出典: Amazon Simple Storage Service ユーザガイド

参考: Amazon Simple Storage Service ユーザガイド

ただ、AWS 公式ドキュメントをいきなり読み始めるのは大変なので
まずはAWS 公式のスライド(BlackBelt シリーズ)から見始めるのがとっつきやすいと思います

出典: 20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier

参考: 20190220 AWS Black Belt Online Seminar Amazon S3 / Glacier

AWS サービスを実際に使ってみる

AWS サービスをより良く使えるようにするための資格なので
実際にサービスを触ってみることは必須だと思います ドキュメントを理解したつもりでも、実際に使ってみると「あれっ」となることはよくあります

何から始めるべきかが分からない方は公式チュートリアルを利用してみても良いですが
試験対策という意味であれば後述の Udemy(動画学習講座)を利用するのがオススメです

Udemy で対策講座を受講する

以下のような特徴のある動画学習サービスです

• プログラミングなど IT 関連の動画が豊富
• 月額〇〇円といったサブスク形式ではなく、1 つ 1 つの動画の買い切り
• 頻繁にセールをやっているのでセール時に買うべき(24,000 円 -> 1,200 円など)

AWS SAA 関連で私が受講したのは以下の 2 つです
(内容は定期的に更新されるため、タイトルが一部異なる場合があります)

• これだけで OK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
• AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集

試験突破講座の良かったと思う点は以下の 2 点です

• ハンズオン形式の講座のため、どの AWS サービスを触りながら理解できる
• 幅広いサービスをカバーし、試験を受ける際に抑えるべきポイントが紹介されている

模擬試験問題集に関しては以下の理由から別のものを選んでも良いと思います

• 問題文・解説に誤字脱字がある
• 実際の試験問題よりも難易度が高かったり、細かすぎる知識を問う問題がある

とはいえ、問題数が多く全問題に対して解説がついているので
上記の点があることを事前に分かっておけば問題ないと思います

疑問に思った内容を適宜調べて理解を深める

講座・問題集の勉強中に疑問に思ったこと、知らなかったことは適宜検索しました
おすすめのサイトは以下の通りです

• AWS 公式ドキュメント
  • やはり基本的には公式ドキュメントです
  • 最初から読み始めるのは骨が折れるので、分からない部分をスポット的に調べると便利です
  • また他のサービスとの比較(例えば SQS と SNS の違いなど)は良くある質問が分かりやすい時が多かったです
  • もちろんAWS 公式のスライド(BlackBelt シリーズ)を見直すのもオススメです
• クラスメソッド
  • クラスメソッドさんは AWS の様々な記事を公開されています
  • 入門者向けの概要記事や試験で問われるような細かい知識の記事も複数存在します
  • 公式ドキュメントよりも図が多く直感的に分かりやすいことが多いです

申込　〜　試験当日

申込〜試験当日で記憶に残っているものを紹介します

試験実施会社の選択に迷った

受験当時、AWS 試験実施会社は「ピアソン VUE」、「PSI」の 2 種類がありました
以下の理由からピアソン VUEを選択しました

• コロナ禍ということもあり、自宅受験が良かった
• パスポートなどの英語圏監督者が分かる身分証明書を持っていなかった

英語の試験官にビビる

日本対応の監督者が良かったのですが、スケジュールが合わず英語対応の監督者の日程で受験しました

特にこちらから英語を話す機会はなかったのですが、
試験中考え込む際、無意識に碇司令のように口元を隠してしまっていたようで
試験画面のチャットで「Don't hide mouth」的な事を言われ「OK」と返信しました
特に問題はなかったのですが、英語が苦手なこともあり、少し焦りました

結果発表はすぐ

試験が終了するとすぐに合否が表示され、証明書や得点比率は後日メールで送られてきました

これから受験を考える方へ

AWS の利用経験や IT 基礎知識がどれくらいあるかにも寄りますが以下の 2 つに分類しました

• 普段から AWS サービスを幅広く使っている方向け
• ほとんど AWS サービスを使ったことがない方向け

(私自身は AWS 歴が約半年でだったので、ちょうど間くらいだったかなと思っています)

普段から AWS サービスを幅広く使っている方

AWS 公式模擬試験を受講するだけでも良いかもしれません
ただ、Web アプリ開発に関連するサービス(EC2, Lambda, DynamoDB など)は触った事あるけど
データ分析系のサービス(RedShift, Kinesis)は触った事がないという場合は苦手なサービスだけ
AWS 公式のスライド(BlackBelt シリーズ)を見つつ触ってみるのが良いかもしれないです

ほとんど AWS サービスを使ったことがない方

以下の流れがオススメです

1. これだけで OK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座 を受講する
2. AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集 などの問題を一通り解いてみる
3. 理解が足りないと感じた問題について良くある質問やクラスメソッドで調べて知識を補う

ポイントとしては以下の 2 点です

• 試験突破講座を受講後に問題を解いてみて、正答率が低くてもめげない
  • 「ちゃんと受講したはずなのに意外と取れないな」と思っても諦めず知識を補充して下さい
• 模擬試験問題集を各回の正当率が 90%以上になるまで繰り返す
  • 1 回目は「とりあえず受けてみる」で正答率 20%とかでも問題ないです
  • 2 回目 or 3 回目あたりで点数が取れてくるようになります

まとめ

今回は AWS ソリューションアーキテクトアソシエイト(SAA)試験の
行った対策、申込〜試験当日、これから勉強する方へのオススメの勉強法について紹介しました
次は AWS ディベロッパーアソシエイト(DVA)を取得したいと思っています