- 0.0.1. AWS IoT CoreとAzure IoT Hubを両方やってみる
- 0.0.2. AWS日記17 (API Gateway)
- 0.0.3. AWS日記16 (Serverless Application Repository)
- 0.0.4. AWS日記15 (Serverless Application Model)
- 0.0.5. RDSはデフォルトパラメータグループはやめよう
- 0.0.6. #1 Djangoのwebアプリケーションをデプロイするまで（AWSのEC2でインスタンス構築編）
- 0.0.7. [AWS] CloudFront + S3 署名付きCookieでHLSコンテンツのプライベート配信
- 0.0.8. S3の静的WebサイトホスティングをCloudFrontでキャッシュしてみる
- 0.0.9. AWS Lambda python「デプロイパッケージが大きすぎてインラインコード編集を有効にできません」の回避方法
- 0.0.10. AWSのOrganization組織のアクセス権をなんとかする
- 0.0.11. 【LVM】論理ボリュームの作成と管理操作
- 0.0.12. 【EC2/Vue/Rails】Vue + RailsのEC2デプロイ手順
- 0.0.13. AWSのRDSClusterの全インスタンスを自動でスペックUPDownするバッチ
- 0.0.14. Amazon CloudFront 概要
- 0.0.15. CloudFormationをゼロから勉強する。（その３：パラメータの入出力）
- 0.0.16. リストを横並び表示にする
- 1. 実現したい事
AWS IoT CoreとAzure IoT Hubを両方やってみる
 
AWS IoT CoreとAzure IoT HubでIoT機器からデータをアップロードするサンプルを試しました。# 手順の比較
| No. | AWS IoT Core | Azure IoT Hub |
| –: | — | — |
| (事前) | – | Azure CLIにエクステンションを追加する |
| (事前) | – | リソース グループを作成する |
| 1 | – | IoT Hubを作成する |
| 2 | モノを作成する | デバイスを作成する |
| 3 | 証明書を作成する | – |
| 4 | ポリシーを作成する | – |
| 5 | 証明書にポリシーをアタッチする | – |
| 6 | 証明書にモノをアタッチする |
AWS日記17 (API Gateway)
# はじめに
今回は API Gateway の WebSocket を試します。
簡易なチャットページを作成します。
[Lambda関数・SAMテンプレート]
(https://github.com/tanaka-takurou/serverless-chat-page-go)# 準備
[AWS SAM CLI環境の準備をします](https://qiita.com/tanaka_takurou/items/cae7c19fc3aaf0031abb)[Amazon API Gatewayの資料]
[Amazon API Gateway](https://aws.amazon.com/jp/api-gateway/)
[Amazon API Gateway とは](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html)
[Amazon API Gateway の料金](https://aws.amazon.com/jp/api-gateway/pricing/)#
AWS日記16 (Serverless Application Repository)
# はじめに
今回は AWS Serverless Application Repository を試します。
サーバーレスアプリケーションを管理するページを作成します。
[Lambda関数・SAMテンプレート]
(https://github.com/tanaka-takurou/serverless-application-management-page-go)# 準備
[サーバーレスアプリケーションの準備をします](https://qiita.com/tanaka_takurou/items/cae7c19fc3aaf0031abb)[Serverless Application Repository](https://ap-northeast-1.console.aws.amazon.com/serverlessrepo/)の「マイアプリケーション」にアプリケーションが表示されている状態にします。
# はじめに
今回は AWS Serverless Application Model (AWS SAM)を試します。
アクセスすると自己削除するWebページを作成します。
[Lambda関数・SAMテンプレート]
(https://github.com/tanaka-takurou/serverless-application-ephemerality-page-go/tree/minimum)# 準備
[AWS SAM CLI をインストールします](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)
[S3の準備をします](https://qiita.com/tanaka_takurou/items/de897b0906087cec1a86)[AWS SAMの資料]
[AWS サーバーレスアプリケーションモデル](https://aws.amazon.com/jp/serverless/s
RDSはデフォルトパラメータグループはやめよう
RDSのMySQLをデフォルトパラメータグループで運用していたのですが、カスタムパラメータグループにしておけばよかったと後悔した話です。
## RDSのInnoDBモニターを有効化したかった。
DeadLockなどのログが見たくてInnoDBモニターを有効化しようと思いました。
有効化にはMySQLのDBパラメータinnodb_status_output/innodb_status_output_locksをONにする必要があります。
ですが、デフォルトパラメータグループのパラメータは変えることが出来ません。
そのためカスタムパラメータグループを作成し付け替えたのですが、パラメータグループの付け替えには必ずインスタンスを再起動する必要がありました。ということでRDSは作成時からカスタムパラメータグループで運用するよう心掛けましょう。
#1 Djangoのwebアプリケーションをデプロイするまで（AWSのEC2でインスタンス構築編）
## インスタンスの作成の仕方
###ステップ１
AWSのEC2を選択し、この画面に移動します。
画面右上の矢印がある所をクリックします。（ここはリージョンというものを選択する所です。）
＊特にこだわりが無ければどこでもいいですが、EC2を使用する前はここを必ずチェックしましょう。
「インスタンスの作成」をクリックします。
###ステップ２
「インスタンスを作成」をクリックすると、この画面に移動すると思います。
ここで仮想サーバを決めます。
今回はUbuntu Server 18.04 LTS (HVM), SSD Volume Type – ami-0bcc094591f354be2 (64 ビット x86) / ami-0bc556e0c71e1b467 (64 ビット Arm)を使います。
![ステップ１マシンイメージ.pn
[AWS] CloudFront + S3 署名付きCookieでHLSコンテンツのプライベート配信
今、作ってる動画配信プラットフォームの備忘録として書きました。
## 構築中プラットフォームのイメージ
今回は、CloudFront + S3でHLSコンテンツを配信する構成に署名付きCookieを使用しプライベート配信を構築を
[【署名付き Cookie を使用して HLS コンテンツを取得してみた】](https://dev.classmethod.jp/articles/get-hls-using-signedcookie/l)こちらを参考に手を動かして実際にやってみた。##署名付きCookieとは
ユーザーに特定のCookieがセットされていればコンテンツにアクセスできる仕組みです。
[【AWS公式ドキュメント】署名付きCookieの使用](https://docs.aws.amazon.com/ja_jp/
S3の静的WebサイトホスティングをCloudFrontでキャッシュしてみる
# はじめに
S3の静的Webサイトホスティングシリーズ第3弾。
S3の静的Webサイトホスティングで遊んでいると、色々な人から「CloudFrontオススメだよ！」と言われるので触ってみた。
CloudFrontって何？というよりは、基本の設定をTerraformで書きながら確認していく感じだ。# 前提条件
– [AWS Black Belt Online SeminarのCloudFront編](https://www.youtube.com/watch?v=mmRKzzOvJJY)をさらっと見ていること。全部理解していなくても問題ないが、これを見て、マネコンでディストリビューションを軽く触ってみたことがないと難しいと思う
– 手前味噌ではあるが、[過去のS3の静的Webサイトホスティングの記事](https://qiita.com/neruneruo/items/d6e8776d3599f483fc55)を読んでおいてもらえると入りが早いと思う# 事前準備(S3バケットの作成)
以下のような感じで、静的WebサイトホスティングしているS3と、そこにコンテンツを突っ込んでお
AWS Lambda python「デプロイパッケージが大きすぎてインラインコード編集を有効にできません」の回避方法
AWS Lambda を python で書いています。パッケージを入れてZIPでアップロードすると、「デプロイパッケージが大きすぎてインラインコード編集を有効にできません」と出て、インラインコード編集が使えません。
これを回避する方法を紹介します。パッケージを別にして AWS Lambda レイヤーに登録します。
# 方法
## 1. python パッケージをフォルダにまとめます
“`
pip install xxx -t ./python/
“`
上記のように書くとpythonというフォルダにパッケージがまとまります。## 2. AWS Lambda レイヤーにアップロード
」の機能は使えない。。## 勘違いしていたこと
(GCPみたいに) プロジェクトに対して複数のアカウントを設定する。のだと思っていたのだけど、AWSの場合はEメールに紐尽くアカウント毎にプロジェクトが存在し、そのプロジェクトの中にEC2だとかIAMだとかが存在する。
なので、AWSの場合はEメールでログインするアカウント=ルートユーザーという位置づけになり、日常の作業はIAMで作ったEメールで一意に特定されないアカウントでの作業になる
## 起きていたこと
現在本番環境が動いている環境は次の様に作られていた
1. master@test.net でアカウントを作成
2. master@test.net が組織を作成し、その組織に old-root@test.net でアカウントを作成した
3. old-root@test.net アカウントでEC2をはじめとした本番環境を構築した
4. old-root@test.net アカウントのメールは開
【LVM】論理ボリュームの作成と管理操作
##目標
LVMを利用して論理ボリュームを作成する。
AWS EC2上での構築とする。##前提
・EC2の構築手順を知っていること。
・LINUXでの基本的なディスク操作方法を知っていること。
・LVMの基本的な概念や用語を知っていること。##LVMとは
物理ディスクや物理パーティションを束ねて、仮想ディスクや仮想パーティションを作成する機能のこと。
LVMを利用することで以下のような物理ディスク上の制約を回避することが可能となります。・**一度パーティションを作成するとサイズ変更が出来ない。**
（⇒LVMでは`lvextend`や`lvreduce`を利用して仮想パーティションのサイズを柔軟に変更することが可能）・**別のディスクにパーティションを移動させることができない。**
（⇒LVMでは`pvmove`を利用してパーティション内のデータを別ディスクに移動させることが可能）・**ディスクのサイズを超える大きさのパーティションは作成できない。**
（⇒LVMでは複数の物理ディスクにまたがって仮想ディスクを構築することが可能なため、所属するディスクサイズ以上のパ
【EC2/Vue/Rails】Vue + RailsのEC2デプロイ手順
# 目次
– **Rubyインストール**
– **Node.jsインストール**
– **Vue.jsインストール**
– **エラー&&対処**# Rubyインストール
####◆ rbenv/ruby-buildインストール
“`
$ git clone git://github.com/rbenv/rbenv.git ~/.rbenv
$ echo ‘export PATH=”$HOME/.rbenv/bin:$PATH”‘ >> ~/.bashrc
$ echo ‘eval “$(rbenv init -)”‘ >> ~/.bashrc
$ source ~/.bashrc
$ git clone git://github.com/rbenv/ruby-build.git /tmp/ruby-build
$ cd /tmp/ruby-build
$ sudo ./install.sh
“`
####◆ Rubyバージョン指定
“`
$ rbenv install -l
$ sudo yum -y install gcc-c++ glibc-headers
AWSのRDSClusterの全インスタンスを自動でスペックUPDownするバッチ
# 概要
表題のバッチをGoで作りました。経緯としては今担当しているサービスが特定の曜日だけ負荷が非常に高まるというサービス特性がありました。Readerが重いだけならスケーリングを時限操作するだけで良いのですが、書き込みが捌けずWriterのスペックを上げる必要があります。Writerのスペックを上げるにはダウンタイムが発生するので人の少ない深夜帯に対応を行う必要があり、毎週深夜対応を行うのは現実的ではなく自動化する運びとなりました。RDSはAuroraのMySQLを使っていて、Writer1台,Reader2台の構成になっています。# 処理の流れ
まずWriterのスペックを上げる流れとしてはReaderをスペックアップし、フェイルオーバー、その後もともとWriter立ったものをスペックアップするという流れになります。本質的にはこれだけなのですが、フェイルオーバーする際にサービスダウンが発生し、それをCloudWatchAlertで拾ってしまうのを避けたく、Alertのアクションを止めるという対応も入れます。# 実装方針
DBのスペックアップもフェイルオーバーもAWS SD
Amazon CloudFront 概要
業務で少し触れるため、学習目的にCloud Frontの概要をまとめる。
## Cloud Frontとは
* ユーザーへ静的/動的ウェブコンテンツを配信するEdge サービス
* Edge Services
* AWSのEdgeロケーションから提供されるサービス群(CloudFront,Route 53,…)
* サービスへのアクセスを、ユーザーに近い場所から提供
### CloudFront利用の背景
#### インターネット経由アクセスにおけるネットワーク遅延
* 物理的、ネットワーク的な距離に応じて、ネットワーク遅延が発生(オリジンサーバーが遠いと、応答に時間がかかる)
#### ネットワーク遅延への対応
* ネットワーク遅延に対応するために、不要なトラフィックをオリジンサーバーに到達させない
CloudFormationをゼロから勉強する。（その３：パラメータの入出力）
# はじめに
前回は`CloudFormation`のデザイナー画面からテンプレートを作成しましたが、固定値をそのまま記載しており、使いまわししにくいので、今回は汎用的にするため、固定値を変数として適宜パラメータを入力させるようにして、後から確認したい値を出力させてみたいと思います。– 【前】[CloudFormationをゼロから勉強する。（その２：デザイナーからのテンプレート作成）](https://qiita.com/sakai00kou/items/5bbb9cfac79fc4a3f857)
# テンプレートパスの確認
前回のテンプレート作成でS3に保存されているテンプレートのディレクトリパスを確認します。`AWSマネジメントコンソール`か`aws cli`で確認してください。
“`shell:aws_cliからの確認
aws s3 ls
aws s3 ls –recursive cf-templates-xxxxxxxxxxxx-[リージョン名]
“`S3にはデザイナー画面で作成したテンプレートが以下のディレクトリパスで保存されているはずです。
“`
リストを横並び表示にする
実現したい事
**・HTMLで作成したリストを横並び表示にしたい**
環境
**・Windows 10
・Amazon Web Service (Cloud9)**手順
1-1
**・HTMLファイルでリストを作成する**
“`html_practice.html
HTMLの練習
- リスト1
- リスト2
- リスト3
- リスト4
“`1-2
**上記の記述の状態でのリストの並び方の画像**
画像のように縦並びになっています。
を使って、ローカルにS3のモックを建てる方法を紹介します。
## MinIOサーバーの起動
MinIOは、下記を実行するだけで（インストールせずに）利用できます。
“`bash
docker run -d -p 9000:9000 –name minio -v $PWD/data:/data \
-e “MINIO_ACCESS_KEY=AKIA0123456789ABCDEF” \
-e “MINIO_SECRET_KEY=0123456789/abcdefghi/ABCDEFGHI0123456789” \
minio/minio server /data
“`– `MINIO_ACCESS_KEY`と`MINIO_SECRET_KEY`は20文字と40文字で適宜変更してください。
– `http://127.0.0.1:9000`でブラウザで管理できます。
– S3の内容はカレン
デプロイを自動化する
##はじめに
「AWSのサーバーを利用する」ための手順を5つに分けて書いています。記事は以下にまとめておりますのでご確認ください。
①[EC2の初期設定](https://qiita.com/maca12vel/items/902dde37a267ceca1c53)
②[本番環境でデータベースを作成する](https://qiita.com/maca12vel/items/68d6ae3d4308e330847d)
③[EC2のRailsを起動する](https://qiita.com/maca12vel/items/2a04d39f958b53d687e2)
④[Webサーバーを設定する](https://qiita.com/maca12vel/items/35f9fb73bb21cb4869fb)
⑤[デプロイを自動化する](https://qiita.com/maca12vel/items/7b33dd6ea1ad556e3fec) ← イマココ##デプロイの自動化
手動で行っていたデプロイ作業（「unicorn_railsコマンド」を使ってサーバーを立ち上げる手段
EC2のRailsを起動する
##はじめに
「AWSのサーバーを利用する」ための手順を5つに分けて書いています。記事は以下にまとめておりますのでご確認ください。
①[EC2の初期設定](https://qiita.com/maca12vel/items/902dde37a267ceca1c53)
②[本番環境でデータベースを作成する](https://qiita.com/maca12vel/items/68d6ae3d4308e330847d)
③[EC2のRailsを起動する](https://qiita.com/maca12vel/items/2a04d39f958b53d687e2) ← イマココ
④[Webサーバーを設定する](https://qiita.com/maca12vel/items/35f9fb73bb21cb4869fb)
⑤[デプロイを自動化する](https://qiita.com/maca12vel/items/7b33dd6ea1ad556e3fec)##EC2上でRailsを起動するための設定
ターミナル（EC2内)で実行
※ 途中で「passphrase」など3段階
バッチサーバーを ”Fargate化” しました
弊プロダクトでもバッチサーバーをFargate化しましたというお話。
*You can also check English subtitle
https://qiita.com/e99h2121/items/513302e1cf1c9ad35367—–
## 何がすごいの
**24/365 バッチサーバーを起動しておかなくても良くなります。**—–
ジョブ同士の関係が限定的になるのでジョブ詰まりがなくなるかも。
とりあえずクラウドフレンドリーな弊プロダクトの大きな一歩（のはず）。—–
試算では年額1社 ****円減
:moneybag::moneybag::moneybag:—–
## ここで唐突に
弊プロダクトバッチジョブ基盤の歴史—–
### Ver.5x– 世界はクライアントとデータベースサーバーしかなかった。夜間バッチはC++のサービスから蹴られていた。
—–
### Ver.6x– 時は2000年代前半、アプリケーションサーバーを介し3層構造化。キュー管理サービスはそのAP Serverに同居。キュ
