Amazon DynamaDBに入門してみた。
今回はAmazon DynamaDBに関してまとめていこうと思います。
最近開発を任されたプロジェクトが、DynamaDBを使用しておりました。
開発するにあたり最低限の知識は抑えたいということで、アウトプットしていきたいと思います。
Amazon DynamaDBとは
DynamaDBは、AWSが開発したマネージドデータベースサービスの一つです。NoSQLに分類されます。
DynamaDBはAmazonのCTOによって開発されました。その背景はCAP定理という「一貫性」「可用性」「ネットワーク分断耐性」を全て達成することはできないという考えがあります。この中で「可用性」「ネットワーク分断耐性」を重視して開発されたのがDynamaDBです。
AmazonECにおいて、”いつでもカートに追加できる=可用性”、”カートに入れたデータを失わない=ネットワーク分断耐性”を、大量に処理することができるDBを目的として開発されました。
DynamoDBの特徴
得意なこと
1. フルマネージドサービスのため、自動的に容量の拡張やレプリケーションが実施される。その他目運用負荷の軽減が可能。
2. key-value およびドキュメントデータモデルをサポートしている点
3. 一行ミリ秒単位のレイテンシーを要求するアプリケーションにも対応していおり、DBMSと異なり非常に高速に実施することが可能な点
4.高可用性
・データの保管時にはデフォルトでデータが暗号化がされる(追加料金不要)
・ポイントインタイムリカバリ (PITR) を使用することで、オペレーションによって DynamoDB テーブルが誤って上書きされたり削除されたりしないようにできる。
・オンデマンドバックアップおよび復元で、DynamoDB テーブルのデータの完全なバックアップを作成してアーカイブできる。
・3つのAZに保存するためデータの信頼性も高い
苦手なこと
1. データのジョインができない
3. 柔軟な検索ができない
4. 集計処理ができない
向いているシステム
1. ミリ秒単位のアクセスレイテンシーが求められるシステム
2. RDBMSのような複雑なデータ構造は扱わないシステム
3. データの容量が予測しにくいシステム
(具体例)
・モバイルゲームにおけるデータ収集
・アカウント管理
・web広告におけるクリックストリーミング
・IOT機器の利用
DynamoDBの設計上の考慮点(キー設計)
DynamoDBはテーブルのデータをパーティションと呼ばれる領域に分けて保持します。つまりデータがどのパーティションに保存されるかはパーティションキーによって決定されます。またパーティションにデータを保存する際は、ソートキーで指定した順序によって保存されます。
このパーティションキー・ソートキーの設定がDynamoDBにおいて重要です。DynamoDBだとクエリが柔軟に発行できないので、設計段階から各種データにどのようにアクセスできるかをきちんと考えておく必要があります。データが多すぎるパーティションはクエリに時間がかかってしまう可能性が発生します。
ポイントインタイムリカバリ (PITR)
DynamoDB テーブルを、偶発的な書き込みや削除のオペレーションから保護できる機能のこと。過去35日間の任意の時点にテーブルを復元することができます。直近の最も遅い復元日時は約5分前までの指定が可能。
既存のテーブルに書き戻しができるわけではなく、あくまでバックアップを復元し、データを確認することができるにとどまります。
キャパシティモード
キャパシティーユニットとは、事前に設定しておく読み込み/書き込み容量のこと。オンデマンドキャパシティーとプロビジョニング済みキャパシティーという 2 種類のキャパシティーモードがあり、これらの二つの料金体系が存在する。
1. オンデマンドキャパシティー
システムがAmazon DynamoDBに対してデータを読み書きした回数に対して料金が発生するプラン。アプリケーションのI/Oの予測がつかないもの向き。
2. プロビジョニング済みキャパシティ
システムがAmazon DynamoDBに対する1秒あたりのデータ読み書き回数を指定し、指定した回数を元に料金が算出されるプラン。Auto Scaling を使用すれば、指定した利用率に応じてテーブルのキャパシティーが自動的に調整されるので、アプリケーションのパフォーマンスを確保しつつコスト削減が可能。
料金体系
料金を決める要素は下記の3つになる。
1. キャパシティーユニット
2. ストレージ容量
3. データ転送量
まとめ
DynamoDBの説明は以上です。
個人的には最初のNoSQLでしたがかなり掴みやすく、直感的な操作が可能なサービスとなっておりました。Dockerにて公式イメージもあるので、ローカル環境でNoSQLを試すのもいいかもしれません。
ただし設計となると話は変わってくるため、導入のハードルは高いものとなっているなという印象です。
最後まで読んでいただきありがとうございました。
Terraformに入門してみた。
今回はTerraformに入門してみたと題して、Terraformとは何者か?ということをざっくり紹介できたらなと思っております。
最近知らない技術に業務で触れる機会が本当に多く、入門記事ばかりですがお付き合いください。
Terraformとは
TerraformはHashiCorpが開発しているIaCツールでGo言語で開発されています。
IaC(Infrastructure as Code)とはインフラをコード化して管理する方法で近年注目されており、こちらを実現するツールの一つとしてTerraformが存在します。競合ツールとして有名なのがAWS CloudfFormationです。
CloudfFormationとの大きな違いとして、「プロバイダーを問わない」点にあります。CloudfFormationはAWS専用のIaCツールですが、TerraformはAWSはもちろん、Azure・GCP等といったほとんど全てのプロバイダーに対応しています。
また独自のTerraformCLIが存在し簡単なコマンドでインフラを作成・削除することが可能です。
Terraformの仕組みと基本コマンド
terraformの仕組みを基本コマンドと一緒に紹介します。
1. terraform init
Terraformの環境を構築したら最初に実行する必要があるコマンドです。Terraformの初期設定を行なってくれるコマンドで、ワークスペースの初期化やプラグインがダウンロードされます
2. terraform plan
terraformの規則に従ってコードを書き終えた時に実行するコマンドです。変更内容が表示されるコマンドで、コードで記載した内容が正しいか確認することができます。
(例 S3バケットをap-north-eastで作成します。みたいな内容が表示される)
3. terraform apply
planで変更内容を確認したら、applyで変更を実行します。コマンドを実行すると変更内容が表示されるので、問題がなければyesを入力します。入力後リソースの構築が実行され、正常に終了すれば完了です。
4. terraform destroy
applyしたリソースを破棄するコマンドです。apply同様コマンドを実行すると破棄対象が表示されるため、問題なければyesを入力します。入力後リソースの破棄が実行され、正常に終了すればリソースが削除されます。
ここまでが流れになります。
流れとは別に一つ整形するコマンドを紹介します。
(番外編)terraform fmt
インデントなどのスタイルをフォーマットするコマンドです。gitにコミットする際等、整形したい時に実行するコマンドです。
tfファイル
terraformのコードを記載する際は拡張子.tfを用いたファイルを使用します。tfファイルの書き方が決まっているのでそのフォーマット(一例)を紹介します。
resource "リソースの種類" "リソース名" {
設定項目1 = 値1
設定項目2 = 値2
設定項目3 = 値3
}
こちらはresourceを記述する際のフォーマットになります。ここでいうresourceは例えばAWSのVPC・サブネット・EC2インスタンス等を指しています。
"リソースの種類"の箇所にVPCやサブネットといった値を設定(書き方は公式ドキュメントを参照)します。
"リソース名"は任意の名前を指定することが可能です。
上記はリソース指定の際の書き方ですが、プロバイダーを指定する際の書き方は別のフォーマットになります。しかしシンプルで分かりやすくそんなに難しく感じないのではないかと思います。
(例)
プロバイダーをAWSを指定。リージョンをap-northeast-1に指定する場合
provider "aws" {
region = "ap-northeast-1"
}
その他記載方法は公式ドキュメントを参照してください。
tfstateファイル
Terraformではデフォルトでtfstateファイルというものが存在します。名前の通りTerraformで管理しているインフラの状態を記録するファイルです。tfstateファイルは自動生成され、保存場所を指定してしない場合Terraformを実行したディレクトリに保存されます。
インフラに変更を加える場合、Terraformはtfstateファイルを見てリソースの追加・変更があるかを判断しています。ローカルにtfstateファイルがあると、メンバーが最新のtfstateファイルからリソースの状況を参照できなくなるため、通常はS3などメンバーが共有できる所で管理します。
Terraform実行環境構築
terraformを実行するために必要なツールはterraformの環境とAWS CLIです。またTerraformを実行するためのAWSクレデンシャルが必要です。terraformの環境はDockerを使って作成することも可能です。
私はAWSクレデンシャルの準備とDockerで環境を構築し実行しています。
まとめ
入門編としてterraformの基礎をまとめてみました。
IaCツールの入門としてこれから入る方には、CloudFormationよりはterraformから入りプロバイダー問わずインフラを作成できる方がいいかもしれないです。
今後本格的にterraformを触っていくので実務で感じたことがあったらまた記事にしてまとめてみようと思います。
最後まで読んでいただきありがとうございましたmm
jestに入門してみた~Matcher編~
今回はjest入門~Matcher編~としてmatcher(マッチャー)についてまとめてみます!
環境構築 - 最初のテストまで編の続きとなりますので、環境構築はこちらを参考にしてみてください。(Vue3+Dockerで環境構築しております。)
URL...
Matcher(マッチャー)とは
マッチャーとは、「テストの評価条件を定義するメソッド」のことです。
マッチするかどうか?の確認をすることを確認するメソッド群と捉えて差し支えないと思います。
主なMatcher
toHaveBeenCalled
モック関数が呼ばれたかどうかを確認するマッチャー。
toBe
等価であることを確認するマッチャー。
toHaveBeenCalledTimes
モック関数が期待した回数だけ呼ばれたことを確認するマッチャー。
toHaveBeenLastCalledWith
最後に呼び出された関数に渡された引数をチェックすることができるマッチャー。
第一引数 想定される値
toHaveReturned
モック関数が少なくとも1回正常に返された(エラーをスローしなかった)ことをテストできるマッチャー
toHaveReturnedTimes
モック関数が指定した回数だけ正常に実行された(エラーをスローしなかった)ことをテストできるマッチャー。
第一引数 number
toHaveNthReturnedWith
モック関数がn回目に返した値が特定の値であるかどうかをテストするマッチャー。
toHaveLastReturnedWith
モック関数が最後に返した値が特定の値であるかテストするマッチャー。
toMatchSnapshot
スナップショットと一致することを確認するマッチャー
モックの全呼び出しの引数・戻り値が前回実行時から変わっていないことをテストする。
toEqual
toStrictEqual
オブジェクト・配列の等価チェックができる。両者の違いは、undefinedの扱い方。
toStrictEqual
の方がより厳密に判定できる
toBeTruthy
toBeFalsy
true falseの判定を行うマッチャー。文字列やオブジェクト型でも判定ができるのが特徴。
undefined null
undefined nullの判定を行うマッチャー。判定は下記の通り。
配列長・文字列長
toHaveLengthマッチャーを使用。
配列や文字列数の判定を行うマッチャー。配列の場合は要素数をカウントしてくれる。
正規表現
toMatchマッチャーを使用する。
文字列を正規表現で判定するマッチャー。
配列要素
toContain toContainEqualマッチャーを使用する。
配列要素がプリミティブ型はtoContain
を使用し、配列要素がオブジェクト型の場合はtoContainEqual
を使用する。
例外処理
toThrowマッチャーを使用する
。引数にはテスト対象のメソッドを関数でラップ。
引数を省略するとエラーが検出されたことのみチェックする。
引数には型・オブジェクト・messageの値を指定できる。
参考
今回はマッチャーについてまとめてみました。
これである程度簡単なテストは書けるようになったのではと思います!
最後まで読んでいただきありがとうございました。
Jestに入門してみた(環境構築 - 最初のテストまで)
こんにちは!
今回はJest入門についてアウトプットしていこうと思います。
会社の新規プロジェクトでNuxtを使用することとなり、Jestをテストフレームワークとして導入しているので、そのキャッチアップの記事になります。
Jestとは
公式ドキュメント
JestはJavaScriptのテスティングフレームワークの一つです。
JavaScriptのフレームワーク(Vue React等)、やシンタックスシュガー(TypeScript)等javaScriptを使用したものは基本使えるものとなっています。
npmかyarnがあれば簡単に導入することが可能です。
特徴として一番はスナップショット機能なのではないかと思っています。フロントエンドのテスト初心者の私にとって、この機能は画期的でした。。
環境構築
今回は、Vue3+Docker環境にJestを導入する方法をご紹介します。
Dockerfile docker-compose.ymlの説明は割愛します。
バージョン情報
docker Version: 20.10.17
docker-compose version 1.29.2
Dockerfile
docker-compose.yml
tree
├── docker
│ └── vue
│ └── Dockerfile
├── vue
| (略)
|
├── docker-compose.yml
こちらの設定で実行すればコンテナが立ち上がるはずです。
docker-compose up -d
コンテナが立ち上がったら、Vueプロジェクトの作成をしていきます。
vue create .
今回はカレントディレクトリにソースを置きたいので上記コマンドを実行します。プロジェクト名を付けたい方は自由に命名してもらって構いません。
ここからプロジェクトを作成していく上でJest関連のものをかいつまんで説明します。
Manuallyを選択
? Please pick a preset: (Use arrow keys)
❯ Default ([Vue 3] babel, eslint)
Default ([Vue 2] babel, eslint)
Manually select features
Unit Testingを選択
? Please pick a preset: Manually select features
? Check the features needed for your project: (Press <space> to select, to t
oggle all, <i> to invert selection, and <enter> to proceed)
◉ Babel
◯ TypeScript
◯ Progressive Web App (PWA) Support
◯ Router
◯ Vuex
◯ CSS Pre-processors
◉ Linter / Formatter
❯◉ Unit Testing
◯ E2E Testing
テストフレームワークの選択>Jestを選択
In dedicated config filesを選択
この4点は注意して後はご自分の好みにカスタマイズして、プロジェクトを作成していください。
自動的にJestが入ったProjectが作成されると思います。
テストファイル
プロジェクト作成されるとtests/unitというディレクトリが自動生成されていると思います。この配下にテストを記述していきます。
tests/unit配下には予めexample.spec.jsというファイルが生成されており、サンプルが自動で用意されています。サンプルのようにテストファイルは.spec.js(あるいは.spec.ts)という拡張子を設定する必要があります。
テスト実行コマンド
今回はnpmを使用して環境を構築しているので下記コマンドで実行できます。
npm run test
上記コマンドをコンテナに入った状態で実行すればテストが実行されるはずです。
簡単なテストの実行
それでは簡単な足し算のテストを実行してみましょう。
test('one + one', () => {
expect(1 + 1).toBe(2);
});
上記を記載した後テストを実行してみてください。
中身は書いてある通りなのですが、こちらは「1+1の結果は2である」というテストです。
テストの実行にはtestメソッドあるいはitメソッドを使用します。
第一引数には、テストの概要の説明を記述し、第二引数に関数形式でテストを記述していきます。テストの概要はテスト実行時のログに出力されます。
今回のテストではexpectとtoBeを使用しております。意味の通り、expectで実行したい式等を記述し、toBeで予想される結果を記述します。今回はそれぞれ式と結果の数値を設定してみました。
このようにシンプルで分かりやすいのがJestのいい所です。
今回は以上になります。
次回以降もう少し深掘りしていこうと思います。
最後まで読んで頂きありがとうございました!!
Nuxt.js入門
こんにちは。
業務でNuxtを使用するので、その入門として調べたことをアウトプットしてみます。
入門として、フォルダ構成・パス・Vuexについて簡単にまとめてみます。
1. Nuxt.jsとは
Nuxt.jsはVue.jsのフレームワークのことです。Nuxt独自の概念もありますが基本的にはVue.jsの知識がそのまま使えるので、Vueができればそう参入障壁も高くないように思えます。
Nuxtのメリットをいくつか挙げると、以下のものがあります。
1. SSRができる
2. PWAモジュールが使用できる
3. head要素の取得が容易にできる
4. ルーティングを自動設定してくれる
5. TSとの互換性
他にもありますが、Vue.jsをさらに強化したもので非常にサクサクと開発できるフレームワークです。
2. Nuxtのフォルダー構成
Nuxtプロジェクトを作成すると自動で必要なフォルダ、ファイルを作成してくれます。その種類と中身は下記の通りです。
.git | gitが使用するもの |
---|---|
.nuxt | Nuxt.jsのアプリケーションが生成されている。デフォルトでは作成されず、npm run dev実行時に生成される |
assets | アプリケーションで使うスタイルシートやJavaScriptファイルなどを配置 |
components | コンポーネントファイルをまとめるフォルダ |
layouts | レイアウトファイルを配置するフォルダ |
middleware | ミドルウェアが配置されているフォルダ |
node_modules | プロジェクトで使用するパッケージ類がまとめられたフォルダ |
pages | 各ページ用のファイルをまとめるフォルダ |
plugins | プラグインのプログラムを配置するフォルダ |
static | イメージファイルなどを保管するフォルダ |
store | データを管理するためのファイルを用意するフォルダ |
.editorconfig | エディター設定情報 |
nuct_config.json | Nuxt.jsの設定ファイル |
package.json |
パッケージ管理ファイル |
この中でも最初はpages store assets staticフォルダをよく使用します。
3. デフォルトページの表示とパス
Nuxtプロジェクトを立ち上げると下記のように表示されるはずです。
こちらのページがどこから読み込まれるのかですが、こちらはpages/index.vueが元に表示されています。各ページのコンテンツはpagesフォルダーにまとめられており、ファイル名がそのままアドレスのパスになります。
例えば/a/a というアドレスのページを作成したいときは、pages/a/a.vueファイルを作成すれば、Nuxtがルーティングしてくれます。Vueの場合は、自身でルーターを設定する必要がありましたが、その必要がないのでNuxtは便利です。
そのためrouter-linkもタグを書くだけでaタグを作成できます。
(例)
4. パラメーターの取得
ID等をGETで送信する場合にパラメーターをどのように取得するのかです。
例えば、http://〇〇/abc/パラメーターで値を送信したいときはpagesフォルダー内にabcというフォルダーを作成し、そこに_〇〇.vueという名前でファイルを用意します。xyzという名前でパラメータを受け取りたい場合は、_xyz.vueファイルを作成します。
パラメーターは$routeという変数のparamsプロパティ内にまとめられています。例えばxyzという名前でパラメータを送った場合は、下記で取り出すことができます。
まとめると/id/passで値を取得したい時、/hanako/1 と送信するとid=hanako pass=1をthis.$route.paramsで取得することができる。
5. Vuex
nuxtにおけるVuexの利用方法は
1. storeフォルダにスクリプトを用意します。そしてstoreフォルダ内のスクリプトにより変数や必要な処理を用意します。
2. $storeを利用します。$storeにはVuexのオブジェクトが保管されており、この中から値などを取り出すことができます。
(例)
store/index.js
$storeの呼び出し(例ではmessageの中身を出力)
5. mutation
コンポーネント側で$store.stateの値を直接書き換える操作は推奨されていない。そのため$store.stateの値操作を行いたいときは、ストア側で値の操作を行う。この操作にはミューテーションという機能を使う。
ミューテーションの機能をコンポーネント側から呼び出すにはcommitメソッドを使用します。commitメソッドでは名前を指定する必要がある。
(例)
clickで$storeに設定されているmutationのcount関数を呼び出す。
click.altで$storeに設定されているmutationのreset関数を呼び出す。
ざっとですが以上になります。
axiosとか、CompositionAPI、その他Nuxtの機能は別記事にてまとめてみたいと思います!!
最後まで読んでいただきありがとうございました!!
php-fpmについてざっと理解する!
こんにちは。
今回はPHP fpmについてまとめてみます。
1年以上PHP開発はしているものの、Vagrantかつインフラ周りを触ってなかったため、PHP-fpmとかそもそもPHPについて詳しく知っていませんでした。Dockerでphp環境を作る際、PHP fpmを使用したので、この機会に調べまとめてみました。
PHPにはモジュール版PHPとCGI版PHPの二種類が存在します。
いくつかの違いがありますが、大きな違いとしてモジュール版PHPはwebサーバー上で動作、CGI版PHPはアプリケーションサーバー上で動作します。そのため「NginxをプロキシしてPHPを起動したい」場合は、CGI版PHPを使用する必要があります。
2. PHPfpmとは
PHP標準のアプリケーションサーバーのこと。fpmはFastCGI Process Manager の略です。PHP5.4.0からサポートされています。
大雑把に理解するならば、「高負荷サイトにおいてパフォーマンスを発揮するためのPHPの一種」であると捉えてもらえればと思います。
3. fpmとは
fpm(FastCGI Progress Manager)とはPHPのFastCGI実装の一つで主に高負荷サイトで有用な追加機能したものになります。
例えば、xさんとyさんが一つのwebサーバーを共有している時、通常処理を実行すると同じプロセスで実行することになります。しかしCGI版だと別ユーザーとして実行されているので、お互いの干渉を防ぐことができます。そのためセキュリティのリスクや他のユーザーへの干渉が及ぶ危険性が低いものになっている。
一方で別プロセスで実行するため処理速度は落ちてしまうデメリットがあります。
4. FastCGIとは
CGIはCommon Gateway Interfaceのこと。これはwebサーバーがブラウザからの要求に応じてプログラムを動作させる仕組みのことです。
具体的には、CGIと比較し、処理速度の高速化と負荷の軽減が期待できます。
CGIではブラウザからの要求に応じて起動したプログラムは、処理が終わり次第プログラム自体も終了します。そのためリクエストが何回も繰り返された場合、いちいち起動・終了を繰り返すことに非効率です。
しかしFastCGIの場合一度起動したプログラムは、一定時間メモリ上で起動したままの状態にしておくことができます。そのためリクエストが繰り返されても、プログラムの起動・終了が一回で済むため、CGIに比べ効率的と言えます。
以上になります。
まとめると、php-fpmはモジュール版PHPに比べて効率良く処理を行い、セキュリティ対策や高負荷サイトへの対応もしたPHPであるといった所でしょうか。これくらい理解しておけばひとまず基礎は抑えられたのではと思います。
最後まで読んでいただきありがとうございました!!
Laravel+Nginx+PostgreSQLのDocker環境を作成する-コンテナ立ち上げからlaravelのトップページを開くまで-
こんにちは。たいきゅんです。
今回はLaravel+Nginx+PostgreSQLのDocker環境を作成する-コンテナ立ち上げまで-の続きの記事になります。
コンテナを立ち上げるまでは完了していることを前提に、composerを使ってLaravelをインストールし、DBと接続するまでの設定を書いていきます。
1. laravelのインストール
phpコンテナ(サービス名はappで設定)したコンテナに入ります。
WORKDIRで設定したとおり、下記のような表示になると思います。
ここでcomposerを使ってLaravelをインストールします。
今回はカレントディレクトリにlaravelをインストールしたかったので、.で設定しました。プロジェクト名を別途設定したい場合は、プロジェクト名を設定して上記コマンドを実行してください。
2. 画面の確認
Laravelのダウンロードが完了したら、localhost:80にアクセスして下記画面が表示されるか確認しましょう。
確認されなかったら、ログを見てエラー解決してください。
3.データベース接続を行う。
DBコンテナと接続を行います。
PostgreSQLコンテナと接続するために、1でダウンロードしたLaravelプロジェクト内にある、.envファイルを編集します。
.env(変更後)
.envファイルに上記項目があるので設定を変更しましょう。
DB_CONNECTION: DBMSの設定。今回はPostgreSQLなのでpgsqlと記載
DB_HOST:DBコンテナ名。今回はdbと設定。
DB_PORT: docker-compose.ymlで設定したportを設定
DB_DATABASE: docker-compose.ymlで設定した初期データベース名を設定
DB_USERNAME: docker-compose.ymlで設定したデータベースユーザー名を設定
DB_PASSPORD: docker-compose.ymlで設定したパスワードを設定
今回はPostgreSQLで実行しますが、MySQLコンテナにしたい場合も基本的に同じで、
DB_CONNECTIONや、imageをMySQLに沿ったものに設定すればできると思います。
こちらを変更したらマイグレーションを実行します
コマンド実行後、エラーが出てなかったらDB接続ができていることになります。
マイグレーションができなかったら、設定関連のミスだと思うので、.envファイルとdocker-compose.ymlを中心に確認してみてください。
マイグレーションができたら環境構築が完了です。
以上になります。
質問等ございましたら、ご連絡頂ければ分かる範囲でお答えします!!
間違っていたらして頂けますと幸いですmm。
最後まで読んで頂きありがとうございました!!