2019-01-15

【nginx】nginx再入門概要と特徴

nginx インフラ

今回はnginxについてです。

nginxについてですが、この記事では主に、概要と特徴についてまとめています。

実際の設定ファイルの記述(記述自体簡単なので、説明しなくもいいが)についてや、モジュールについての細かい説明はしていません。

基本的な部分を軽く抑えておきましょう！

Nginx

概要

Nginxはロシア生まれの軽量HTTPサーバーである。非同期ソケットを使用していて、要求を受け取った回数と同じだけの 子プロセス を作成したりはしない。これはCPUの負荷とメモリの消費量を大幅に下げることができる。1つのコアに1つのプロセスがあれば、数千の接続を処理できる。設定ファイルも読みやすく、非常に強力なプラグインシステム、モジュール を備えているのも特徴である。

設定ファイル概要

基本的に nginx.conf ファイル(分割可)は directive(ディレクティブ) 構造で記述する。大きく2つに分類される。

simple directive(基本ディレクティブ) 設定項目設定値;
block directive(ブロックディレクティブ) 設定項目名A { 設定項目名B 設定値B; }

ディレクティブはモジュールによって導入される。例えば、デフォルトで含まれているeventsブロックがあるが、Eventsモジュールが有効にするディレクティブはeventsブロックでしか定義できない。また、httpブロック内では、1つ以上のserverブロックを定義できるように、サーバーに対してグローバルな影響を与えるディレクティブも存在する。

最後に重要な点として、継承についてである。 http, server, locationブロックが主に上位ブロックとして存在する。(その他、root, eventブロックなど)

以下のような例だとする。

http {
    server {
        charset utf-8;
        listen 80;
        server_name test.co.jp;
        index index.html index.htm;

        location  /  {
            index index.php;
        }
        location /test/ {
            index test.php;
        }
    }
}

locationブロックが2つあり、serverブロックに属している。この時、serverブロックに宣言されている、utf-8やlisten 80の設定は2つのlocationブロックにも適用される。つまり、あるlocationに対して、独自の設定を宣言したい場合は、locationブロック内で宣言する。

私の経験として、設定ファイルを分割し継承がごちゃごちゃになって、正常にサーバーがレスポンスを返してくれなくなったことがありました。。ブラウザでネットワークまわりのエラーがでたら、nginxの設定をよく見直してみること。

C10K問題

C10K問題 とは、ハードウェアの性能上は問題なくとも、クライアントの数があまりにも多くなるとサーバーがパンクする問題のことである。 C = Client、10K = 1万という意味で、クライアント1万台問題ともいわれる。

C10K 問題とは - はてなキーワード

これは概要で書いてある特徴の1つで、Nginxのアーキテクチャが肝になってくる。主に、マスタープロセスとワーカープロセスが立ち上がり、

マスタープロセスは、ワーカープロセスの立ち上げや制御、管理などを担い、ワーカープロセスは、複数のリクエストを処理する。

Apacheのデフォルトのアーキテクチャなどでは、1リクエストに対して、1プロセスが処理していくことになるので負荷がかかりやすい。 Nginxはこうして、C10K問題を解決している。また、この仕組みによって、リバースプロキシなどの用途としてよく活用されていることに説明がつきそうである。

2019-01-10

【AWS】EC2のJavaをヴァージョンアップする

AWS EC2 Java インフラ

今回は、EC2のJavaのヴァージョンを上げる方法です。

対象は、AmazonLinux1です。 AmazonLinux2では試していませんので、ご承知ください！

それでは、さっそくやっていきます。

確認

まず、今インストールされているJavaのヴァージョンを確認します。

$ java -version

java version "1.7.0_201"
OpenJDK Runtime Environment (amzn-2.6.16.0.78.amzn1-x86_64 u201-b00)
OpenJDK 64-Bit Server VM (build 24.201-b00, mixed mode)

この例では、ヴァージョン7の更新201という意味になります。更新はいいとして、ヴァージョンを今回は7から8に上げようかと思います。

インストールできるjavaを確認

yumでインストール可能なjavaを探します。

$ yum search java | grep java-1.8*

java-1.6.0-openjdk.x86_64 : OpenJDK Runtime Environment
java-1.6.0-openjdk-demo.x86_64 : OpenJDK Demos
java-1.6.0-openjdk-devel.x86_64 : OpenJDK Development Environment
java-1.6.0-openjdk-javadoc.x86_64 : OpenJDK API Documentation
java-1.6.0-openjdk-src.x86_64 : OpenJDK Source Bundle
java-1.7.0-openjdk.x86_64 : OpenJDK Runtime Environment
java-1.7.0-openjdk-demo.x86_64 : OpenJDK Demos
java-1.7.0-openjdk-devel.x86_64 : OpenJDK Development Environment
java-1.7.0-openjdk-javadoc.noarch : OpenJDK API Documentation
java-1.7.0-openjdk-src.x86_64 : OpenJDK Source Bundle
java-1.8.0-openjdk.x86_64 : OpenJDK Runtime Environment
java-1.8.0-openjdk-demo.x86_64 : OpenJDK Demos
java-1.8.0-openjdk-devel.x86_64 : OpenJDK Development Environment
java-1.8.0-openjdk-headless.x86_64 : OpenJDK Runtime Environment
java-1.8.0-openjdk-javadoc.noarch : OpenJDK API Documentation
java-1.8.0-openjdk-javadoc-zip.noarch : OpenJDK API Documentation compressed in
java-1.8.0-openjdk-src.x86_64 : OpenJDK Source Bundle

1.6～1.8までがどうやらインストールできるようですね。 Javaの種類というのも変かもしれませんが、いくつかタイプがあります。

JDK java-1.8.0-openjdk-devel.x86_64 (開発環境) java-1.8.0-openjdk.x86_64 (ランタイム)

JDK(Java SE Development Kit)とは、Javaのプログラムを開発する際に必要なもので、

JRE(Java Runtime Environment)は、Javaを実行する際に必要なものです。

JDKにJREは同梱されていますが、別物として理解しておくといいかもしれません。ここでは細かいJavaについては説明しません！

インストール

$ sudo yum install java-1.8.0-openjdk-devel.x86_64
(上記をインストールすれば、java-1.8.0-openjdk.x86_64もインストール済なはずです)

# 確認
$ yum list installed java-*

Installed Packages
java-1.7.0-openjdk.x86_64                                  1:1.7.0.201-2.6.16.0.78.amzn1                         @amzn-updates
java-1.8.0-openjdk.x86_64                                  1:1.8.0.191.b12-0.42.amzn1                            @amzn-updates
java-1.8.0-openjdk-devel.x86_64                            1:1.8.0.191.b12-0.42.amzn1                            @amzn-updates
java-1.8.0-openjdk-headless.x86_64                         1:1.8.0.191.b12-0.42.amzn1                            @amzn-updates

インストールしただけでは、ヴァージョンは変わっていないはずです。

有効化

複数のバージョンがインストールされているとき、システムがどのバージョンを使用するかを設定できるように

alternativesコマンドを実行して指定します。

$ sudo alternatives --config java


There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
   2           /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java

Enter to keep the current selection[+], or type selection number: 2 # ←ここで"2"を入力

実に簡単ですね！

ここで再度Javaのヴァージョンを確認すると、1.8.0_XXXで変更が確認できるかと思います。

以上.

2018-12-27

【AWS】AWSホワイトペーパー概要まとめ

AWS EC2 IAM インフラ

今回はAWSのホワイトペーパーという、 AWSにおけるアーキテクチャやセキュリティについてなどのトピックが載っている資料をまとめました。

(随時更新中～～～～～～～～～～～～～～～)

意図としては、AWSの資格である、AWS ソリューションアーキテクトにおいて AWSサービスを抑えておくために良さそうなホワイトペーパーを読んでみようということでこの記事を作成しました。

ホワイトペーパー | AWS

たくさんトピックがあるので、まずAWSの概要(2017年4月)が載ったPDFをまとめました。資格取得のために必要な知識として、足りてないことが多いです。。

なので一旦、AWSのサービスとして、「こんなサービスあるのか～」くらいの内容になります。

より詳しく深堀していく必要があったり、もちろん実際サービスを使用してみるのが一番良いのであくまでもサービスの自分用メモ程度になります。

私の場合、仕事でけっこうAWSのサービスを使用する機会があるのですが、業務上、しっかりと理解できていなかったり、このサービスを調べる時間がなかった…みたいなかんじだったので、今回内容は薄いものの、まとめてみてもっと機能について深堀したくなるような気持ちになったので良かったです。それにAWS独特な単語とか言い回しも、書いていて少し身に入った気もしますｗ

日本語の資料は2017年のものなので、それ以降リリースされたサービスは記載していません！ただ、私が使用していて、最近出た機能でわかるものは記載しました。(随時更新できたらいいなああ)

AWS ホワイトペーパー (概要)

クラウドコンピューティングとは？

クラウドコンピューティングとは、インターネットを経由したクラウドサービスプラットフォームのこと。従量課金制でITリソースを提供する。ハードウェアへの多額な投資が不必要になる。

クラウドコンピューティング6つの長所

固定費が変動費へ
スケールによる大きなコストメリット
キャパシティーの推測が不要に
速度と迅速性の向上
データセンターの運用や保守への投資が不要に
グローバル化を即座に達成

クラウドコンピューティングのタイプ

クラウドコンピューティングのモデル

Iaas

Infrastructure as a Serviceには、基本構築ブロックにあたる。ネットワーキング機能、コンピュータ、データストレージスペースへのアクセスを提供。

PaaS

Platform as a Serviceには、業務をより効果的に進められるように、組織で基盤インフラストラクチャを管理する必要がない仕組みが用意されている。自社アプリの開発と管理に集中できる。

SaaS

Software as a Serviceには、サービスプロバイダによって実行及び管理される完成品を適用する。

クラウドコンピューティングのデプロイモデル

クラウド

クラウドベースのアプリは完全にクラウド上でデプロイされ、実行されている。これは、クラウドコンピューティングのメリットを活用するために既存のインフラストラクチャから移行されたものもある。低レベルのインフラストラクチャからインフラストラクチャのスケーリング要件からの抽象化を提供する高レベルなサービスをアプリを作成する上で使用できる。

ハイブリッド

ハイブリッドデプロイとは、クラウドベースのリソースと、クラウド上にはない既存のリソースとの間でインフラストラクチャとアプリを接続する方法である。一般的なものとしては、クラウドと既存のオンプレミスインフラストラクチャ間を接続し、クラウドのリソースを内部システムに接続しながら組織のインフラストラクチャをクラウドに拡張・成長させることである。

オンプレミス

仮想化及びリソース管理ツールを使用してリソースをオンプレミスでデプロイすうｒことを、プライベートクラウドと呼ぶ。

グローバルインフラストラクチャ

AWSには、190を超える国々に100万を超えるアクティブなお客様がいる。グローバルなインフラストラクチャを拡大しており、低レイテンシーおよび高いスループットを実現し、データが確実に指定された地域内にのみ保存されるようにしている。 AWSインフラストラクチャは、リージョンとアベイラビリティーゾーン(AZ)を中心とし構築されている。リージョンは、世界中の物理的場所であり、リージョンに複数のAZが配置されている。 AZは1つ以上の独立したデータセンターで構成されている。各データセンターは、冗長性のある電源、ネットワーキング、および接続性を備えており別々の設備に収容されている。このようなAZによって、高い可用性、耐障害性、拡張性を実現している。 AWS クラウドは世界中の20の地理的リージョンにある60のアベイラビリティーゾーンで運用されている。(2018.12現在) https://aws.amazon.com/jp/about-aws/global-infrastructure/ 各AZは独立しているが、同じリージョン内のAZ同士は低レイテンシーのリンクで接続されている。また、AZは洪水の影響が及ばないような場所にある。

セキュリティとコンプライアンス

セキュリティ

クラウドセキュリティAWSの最優先事項である。クラウドであ、物理的なサーバーまたはストレージ機器を管理する必要がない代わりに、ソフトウェアベースのセキュリティツールを使用して、クラウドリソースを出入りする情報の流れを監視し保護する。 AWSでは、クラウドのセキュリティを管理する一方、クラウド内のセキュリティについてはｍお客様ので責任である。つまり、所有するコンテンツ、プラットフォーム、アプリケーション、システム、ネットワークを保護するために実装するセキュリティの管理権限を保持しているということになる。 AWSセキュリティの利点は以下が挙げられる。

データの保護
コンプライアンスの要件に準拠
コスト削減
迅速なスケーリング

コンプライアンス

AWSがお客様に提供するITインフラストラクチャは、セキュリティのベストプラクティス、および各種ITセキュリティ基準に合わせて設計・管理されている。

SOC1/ISAE 3402, SOC 2, SOC 3
FISMA, DIACAP, FedRAMP
PCI DSS レベル1
ISO 9001, ISO 27001, ISO 27018

AWSプラットフォーム

AWSマネジメントコンソール

シンプルで直感的に操作できるユーザーインターフェースである。また、AWSコンソールモバイルアプリを利用して、使用中のリソースを表示することも可能。

AWS コマンドラインインターフェース

CLIは、AWSのサービスを管理するための統合ツールである。ダウンロードおよび設定用の単一のツールのみを使用して、コマンドラインから複数のAWSサービスを生業し、スクリプトを使用してこれらを自動化することができる。

Software Development Kits

SDKうぃ使用すると、アプリケーションプログラムインターフェース(API)をユーザーのプログラミング言語または、プラットフォーム用に調整して、AWSのサービスをユーザーのアプリケーションで用意に利用できる、

(以下、サービス名先頭につく、"Amazon"は略)

コンピューティング

EC2

EC2は、安全で規模の変更が可能なコンピューティング性能をクラウド内で提供されている。新規サーバーインスタンス(以下インスタンス)の取得と起動に要する時間は分単位にまで短縮される。キャパシティーの拡張や縮小も、要件に合わせてすばやく実行可能である。料金は、実際に使用したキャパシティーの分だけ。

メリットは、以下。

弾力性のあるウェブスケールコンピューティング

数分以内に能力の増減を行うことが可能。 1つのインスタンスでも数千のインスタンスでも同時に作動させることができる。すべてがAPIでコントロールされるので、アプリのニーズに応じた自動的なスケールアップ/ダウンが可能。

安全な制御が可能

インスタンスは完全に自身で管理できる。インスタンスを停止しても、ブートパーティション上のデータは保持することができ、APいを使用すれば、リモートでインスタンスをリブートすることができる。

柔軟なクラウドホスティングサービス

様々なインスタンスタイプ、オペレーションシステム、ソフトウェアパッケージを選択できる。 EC"はアプリに合わせた最適なメモリ設定、CPU、インスタンスストレージ、ブートパーティションサイズも選択可能。例、オペレーションシステムの選択では、LinuxディストリビューションやMicrosoftWindowsServerも含まれている。

統合

S3やRDSなどのAWSのほかサービスと統合され、クエリ処理、クラウドストレージの安全な総合ソリューションを提供。

信頼性

インスタンスの置き換えには、あらかじめ指定した条件で実行できる。これは、ネットワークインフラストラクチャとデータセンターの中でカ稼働している。 EC2は、各リージョンにおいて、99.95%の可用性を約束している。

セキュリティ保護

EC2はVPCと連携して動作し、安全性と堅牢なネットワーキング機能を提供。

VPC内では、指定したIPアドレス範囲を持っており、インターネットに公開されるインスタンスとプライベートな状態のままにするインスタンスを決定する。

セキュリティグループとネットワークアクセスコントロールリスト(ACL)により、インスタンスを出入りするインバウンドとアウトバウンドのネットワークアクセスを制御することができる。

VPNを使用して既存のITインフラストラクチャをVPC内のリソースに接続することができる。

EC2リソースは、ハードウェア専有インスタンスとして、プロビジョンできる。ハードウェア専有インスタンスは、分離性を高めるために単一の顧客専有のハードウェア上で実行されるEC2インスタンスである。また、ハードウェア専有ホストにプロビジョンできる。これは専用のEC2インスタンスキャパシティーを備えた物理サーバーのこと。

安価

オンデマンドインスタンスは、長期間の契約なしに、時間単位でコンピューティング性能に対して料金を支払う。リザーブドインスタンスは、オンデマンドインスタンスの料金と比べて大幅な割引(最大75%)を受けられる。スポットインスタンスとは、スペアのEC2のコンピューティング性能の価格を指定できるシステム。

インスタンスタイプについて

EC2のインスタンスタイプは、t2.microのように表記される。この先頭t2は世代を表しておりインスタンスファミリー、その後のmicroはインスタンスサイズを表している。

インスタンスファミリーは用途に分類されたものである。

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

それぞれ種類が多いので、以下公式から参考にする。

aws.amazon.com

インスタンスタイプを選択するにあたって重要なのは、負荷である。もちろん、規模やvCPU、メモリなどを目的に合わせて選択する。

選択するにあたって1つの指標となるサイトが以下。 (表示されている情報は、Githubで公開されている。)

www.ec2instances.info

GitHub - powdahound/ec2instances.info: Amazon EC2 instance comparison site

EC2 Container Service (ECS)

ECSは、Dockerコンテナをサポートするスケーラビリティに優れた高性能なコンテナ管理サービス。 EC2インスタンスのマネージド型クラスターで簡単にアプリを実行できる。また、ELB、EBSボリューム、IAMロールなどの多くの使い慣れた機能にアクセスしたりできる。

EC2 Container Registry (ECR)

ECRは、開発者がDockerのコンテナイメージを簡単に保存、管理、デプロイできるマネージド型のDockerコンテナレジストリ。 ECRはECSに統合されているため、開発から本番までのワークフローｗｐ簡略化できる。このサービスには、前払い料金や長期契約はない。リポジトリに保存したデータ量とインターネットに送信されたデータ量に対してのみ料金が発生。

Amazon Lightsail

AWSで仮想プライベートサーバーを起動および管理する最も簡単な方法として設計されている。 (UIもなんだかポップなかんじで、最低限のプライベートサーバーを構築できよってかんじでした。)

AWS Batch

サブミットされたバッチジョブのボリュームや特定のリソース要件に基づいて、最適な量と種類のコンピューティングリソースを動的にプロビジョニングできる。 AWS Batchを使用すればジョブを実行するためのソフトウェアやサーバークラスターなどインストールしたり、管理したりする必要がなくなる。

Elastic Beanstalk (EB)

EBは、Java, .NET, PHP, Node.js, Python, Ruby, Go及びDockerを使用して開発されたウェブアプリやサービスを Apache, Nginx, Passengerなど使い慣れたサーバーデプロイとスケーリングするための使いやすいサービス。コードをアップロードするだけで、EBがキャパシティーのプロビジョニング、負荷分散、Auto Scalingからアプリのモニタリングまで、デプロイを自動的に処理する。

Lambda

サーバーをプロビジョニングまたは管理しなくてもコードを実行できる。コンピューティング時間で料金が発生するので、コードが実行中でなければ料金がかからない。コードのアップロードだけで、コード実行やスケールに必要な処理はLambdaが自動的に実行してくれる。他のAWSサービスから自動的にトリガーするように設定することができるので、高い可用性である。

Auto Scaling

アプリのアプリケーションの可用性を維持でき、EC2の能力を自動的に縮小・拡張できる。需要パターンが安定しているアプリにも、変動するアプリにも適している。

ストレージ

S3

S3はシンプルなウェブサービスインターフェースを使用して、ウェブ上のどこからでも容量に関係なくデータを保存・取得できるオブジェクトストレージ。 99.999999999%の耐久性を提供している。分析用の一括リポジトリ(データレイク)やバックアップ、復旧用、災害用として利用できる。また、サーバーレスコンピューティングにも利用可能。

S3の特徴は以下が挙げられる。

シンプル

S3ではREST APIやSDもすべて用意されているので、サードパーティー製テクノロジーの組み込みも簡単。

耐久性

重要なデータを保存するための耐久性のあるインフラストラクチャを提供しており、オブジェクト(ファイルなどを指す)の99.999999999%の耐久性の耐久性を実現。データは冗長化されて複数の施設に保存され、各施設で複数のデバイスに保存される。

スケーラブル

ストレージニーズを世族しなくても大丈夫。

セキュリティ保護

SSLでのデータ転送と、アップロード後のデータを自動暗号化をサポート。 IAMを使用して、オブジェクトのアクセス権限を管理しデータへのアクセスを制御するバケットポリシーを設定することができる。

使用可能

スタンダードで、年間最大99.99%のオブジェクトの可用性を提供するように設計されている。サービス」レベルアグリメントに裏付けている。 AWSコンソール、右上のリージョン選択からではないが、リージョンの選択が可能。

低コスト

非常に低いコストで大量のデータを保存できる。さらにコストの削減をしたいなら、ライフサイクルポリシーを使用して、古くなったデータを自動的に標準(低頻度アクセスなど)に移行したりできる。

シンプルなデータ転送

S3の内外に移動することも容易にできる。

統合

様々なAWSサービスと密接に統合されている。

管理が容易

ストレージ最適化、データセキュリティ、管理効率に対するデータ駆動型のアプローチをとることができる。

EBS

EC2で使用する永続的なブロックレベルのストレージボリュームを提供。 EBSはボリュームはAZ内で自動的にレプリケートされる。 EC2は、本体にインスタンスストア(記憶領域)を持っているが、サーバーの停止などで初期化を行う特徴がある。なので、EBSを使用してこの仕様に対策を行うことができる。(イメージとしては、外付けHDDのようなかんじ)

特徴として、以下。

高性能なボリューム

アプリのパフォーマンスに合わせてSSDかHDDのいずれかを選択。

アベイラビリティー

EBSの各ボリュームは可用性99.999%になるように設計されている。 AZ内で自動的にレプリケートされる。

暗号化

保管中のデータと転送中のデータがインスタンスとEBSボリュームの間でシームレスに処理される。

アクセス管理

EBSボリュームにアクセスできるユーザーを指定できる。

スナップショット

ポイントインタイムスナップショットを作成することで、データを保護できる。作成されたスナップショットは、長期保存のためいにS3にバックアップされる。

Elastic File System (EFS)

EC2と共イン使用するための、スケーラブルなファイルストレージシステムであり。ストレージ容量は伸縮自在で、ファイルを追加/削除すると自動的に拡大/縮小する。

複数のEC2が1つのEFSファイルシステムに同時接続することができるので、複数のEC2インスタンスに対して共通のデータソースを提供できる。

ビッグデータと分析、メディア処理ワークフロー、コンテンツ管理、ウェブ配信など高い可用性を活かしてパフォーマンスを発揮できる。

以下、各ストレージサービスとの主な違いを比較。

	S3	EBS	EFS
スループット	最も遅い	1秒あたり1GB	1秒あたり数GB
AZ(保存先)	複数	1AZ	複数
アクセス	複数のAZとインスタンスから同時、及びインターネット公開可能	単一AZの単一インスタンスからのみ	服すAZの複数インスタンスから同時

Glacier

データのアーカイブおよび長期バックアップを行うための、安全性と耐久性に優れていて、低コストのストレージサービスである。簡単にいうと、アクセス頻度が低いが、低コストで削除したくないデータの保持に適しているのはないでしょうか。 S3より低価格です。(1Gあたり月額約0.004USD)

Storage Gateway

オンプレミスストレージ環境とAWS クラウド間のシームレスなハイブリッドストレージが可能。一例としては、オンプレのデータのバックアップなどを目的として利用できる。

データベース

Aurora

Auroraは、MySQL、PostgreSQLと互換性のあるリレーショナルデータベースで、オープンソースデータベースのシンプルさとコスト効率性で備えられている。高性能の商用DBの可用性とスピードを併せ持っている。MySQLの最大5倍のパフォーマンスを発揮。

以下、メリット。

高性能

標準的なMySQLの最大で5倍のスループット、また、PostgreSQLの2倍のスループットを実現。コストが1/10でありながら、最大規模のAuroraでは、秒あたり最大500,000会の読込と最大100,000会の書込を達成できる。さらに小さい10msのレイテンシーを実現するリードレプリカを使用することで、読込オペレーションをさらにスケールするこｔこも可能。

高い安全性

複数のレベルのセキュリティが用意されている。VPCでのネットワーク分離、KMSを使用して作成および制御するキーを使用した保管時の暗号化、及びSSLを使用した転送中データの暗号化など。また、基盤ストレージ、同じクラスター内にある自動化バックアップ、スナップショット、レプリカも暗号化されている。

MySQLとPostgreSQLとの互換性

InnoDBストレージエンジンを使用。

高スケーラブル

Auroraは、2vCPUと4GiBのメモリを備えたインスタンスから、最大で32vCPUと244GiBのメモリを備えたインスタンスまでスケールできる。 3つのAZにかけて最大15個の低レイテンシーリードレプリカを追加することで、さらに読込容量をスケール可能。 Auroraは、10GB～64TBまで必要に応じて自動でストレージを拡張する。

高可用性と耐久性

99.99%の可能性を提供するように設計されている。インスタンスのフェイルオーバーは、通常30秒未満で完了する。データは6つのコピーが3つのAZにわたってレプリケートされ、連続的にS3にバックアップされる。

完全マネージド型

自動的にDBがモニタリングされ、S3にバックアップされるので、細かいポイントインタイムリカバリが可能。

RDS

クラウド内のリレーショナルデータベースのセットアップ、運用、スケールが簡単である。 Aurora、PostgreSQL、MySQL、MariaDB、Oracle、MicrosoftSQLServerのDBエンジンから選択できる。

以下、メリット。

管理がすばやく簡単

DBのメンテナンス、ソフトウェアのインスタンスはインストールは不要である。 AWSマネジメントコンソールやAPIコールでアクセスが可能。

高スケーラブル

ダウンタイムなくDBのコンピューティング容量とストレージ容量をスケールできる。 1つ以上のリードレプリカを起動でき、プライマリデータベースインスタンスの読み取りトラフィックによる負荷を軽減できます。

可用性と耐久性

マルチAZDBインスタンスをプロビジョンする際に、データを別のAZにあるスタンバイインスタンスに同期的にレプリケートする。自動バックアップ、DBスナップショット、ホスト自動交換といったその他の特徴を多数備えている。

セキュリティ保護

DBへのネットワークアクセスの制御も簡単。

安価

実際に利用したリソース分に対してのみ支払う。

DynamoDB

数ミリ秒台にレイテンシーを抑える必要のあるアプリケーションに適した、高速で柔軟性の高いNoSQLデータベース。ドキュメントとキー値のデータモデルの両方をサポートしている。ウェブ/モバイルアプリは勿論、ゲームやIoTなど多くのアプリケーションで活躍できる。

以下、メリット。

高速で安定したパフォーマンス

通常、サービス側の平均レイテンシーは1桁台のミリ秒単位。

高スケーラブル

テーブル作成時は、必要なリクエスト容量を指定するだけ。スループット要件が変わった場合は、コンソールかAPIを使用して、テーブルのリクエスト容量を更新できる。スケーリングの進行中でもスループットレベルを実現することができる。

完全マネージド型

完全マネージド型NoSQLデータベース。テーブルを作成し、スループットを設定するだけ。

イベント駆動型プログラミング

Lambdaと統合することで、トリガーを提供。

細かいアクセスコントロール

IAMを統合しているため、組織内のユーザーのアクセスを細かく制御することができる。各ユーザーのサービスとリソースへのアクセスを制御できる。

柔軟

ドキュメントとキー値のデータモデルの両方をサポートしている。

ElastiCache

インメモリキャッシュのデプロイ、運用、スケーリングをクラウド内で簡単に実行できるサービスである。低速のディスクベースのDBに完全に依存せず、高速の管理されたメモリ内のキャッシュから情報を取得し、アプリケーションのパフォーマンスを向上させる。

Redis

高速なオープンソースのインメモリ型データストアおよびキャッシュ。シングルノードおよび最大15シャードのクラスターが利用でき、最大3.55TiBのインメモリデータまでのスケーラビリティが実現されている。

Memcached

メモリオブジェクトキャッシュシステム。ElastiCachehaは、Memcachedに準拠するプロトコルである。

移行

ネットワーキングとコンテンツ配信

VPC

AWS クラウドの論理的に分離されたセクションをプロビジョニングし、定義した仮想ネットワーク内のAWSリソースを起動する。独自のIPアドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定などをコントロールする。 IPv4とIPv6の両方を使用できる。ネットワークの設定が容易にできる。各サブネットのEC2インスタンスへのアクセスコントロールできる。 VPN接続も可能。

CloudFront

グローバルなコンテンツ配信ネットワーク(CDN)サービスである。ウェブサイト、API、動画コンテンツなどウェブ資産の配信を高速化できる。コンテンツリクエストは、自動的に最寄りのエッジロケーションにルーティングされる。大量のリクエストに対して通信にかかるレイテンシを改善する。コンテンツの配信量によって料金が発生する。

Route 53

ドメインネームシステム(DNS)ウェブサービスである。 Route 53は、IPv6にも対応している。 EC2、ELB,S3バケットなどのAWSで実行するインフラストラクチャにユーザーリクエストを効率的に接続する。これはAWSの外部のインフラストラクチャにルーティングするためにも使用できる。ドメイン名登録も提供。ドメイン名を購入でき管理もできる。

Direct Connect

AWSとデータセンター、オフィス、またはコロケーション環境間にプライベート接続を確立することができる。

Elastic Load Balancing (ELB)

アプリケーションのトラフィックを複数のEC"インスタンスに自動的に分散させる。

3つのタイプのロードバランサーが提供されている。

Classic Load Balancer

アプリケーションまたはネットワークレベルの情報に基づいてトラフィックをルーティングする

Application Load Balancer

リクエストのコンテンツを含む拡張アプリケーションレベル情報に基づいてトラフィックをルーティングする

Network Load Balancer

クライアントにとって単一の通信先として機能し、秒間何百万リクエストを捌くように設計されている https://aws.amazon.com/jp/blogs/news/new-network-load-balancer-effortless-scaling-to-millions-of-requests-per-second/

	CLB	ALB	NLB
概要	旧型の汎用型	HTTP/HTTPS専用	TCP専用
レイヤー	L4/L7	L7	L4
プロトコル	TCP,SSL,HTTP,HTTPS	HTTP,HTTPS	TCP
ヘルスチェック	可	可	可
バランシング方式	ラウンドロビン	パスベース,ホストベース	ハッシュベース
タイムアウト設定	可(1-3600秒)	可(1-3600秒)	不可
SSLオフロード	可	可	不可
ログ記録先	S3	S3	CloudWatch

開発者ツール

CodeCommit

完全マネージド型ソースコントロールサービス。プライベートGitリポジトリを簡単にホスティングできる。

CodeBuild

完全マネージド型構築サービス。ソースコードのコンパイル、テストの実行、すぐにデプロイできるソフトウェアパッケージの生成を行う。ビルドサーバーのプロビジョニングが不要になる。

CodeDeploy

様々なインスタンスへのコードのデプロイを自動化するサービス。アプリケーションのデプロイ中のダウンタイムをなくすことや、アプリの複雑な更新を処理することができる。

CodePipeline

アプリケーションとインフラストラクチャの更新を実現するための継続統合および継続配信サービス。コードの変更があるたびに、ビルド、テスト、デプロイを実施する。 Githubなどのサードパーティーサービスにも対応できる。

X-Ray

https://aws.amazon.com/jp/xray/

管理ツール

CloudWatch

AWS上で実行するアプリケーションをモニタリングするサービス。メトリクスの収集と追跡、ログファイルの収集とモニタリング、アラームの設定などが可能。リソースの使用率、アプリのパフォーマンス、オペレーションの状態について可視性を得ることができる。

EC2 Systems Manager

https://aws.amazon.com/jp/systems-manager/

CloudFormation

AWSリソースのコレクションを開発者やシステム管理者が容易に作成、管理し、整った予測可能な方法でプロビジョニング/更新できるようにするサービス。サンプルプレートとよばれる、必要な関連する依存関係などを記述し、アプリケーションなどを実行します。依存関係が機能するように細かく記述する必要はなく、CloudFormationが自動で代わりに行う。

CloudTrail

アカウントのAWSのAPI呼び出しを記録し、ログファイルを送信すりサービス。セキュリティの分析やリソース変更の追跡などを行うことができる。

Config

セキュリティとガバナンスを可能にするため、AWSリソースのインベントリ、構成履歴、構成変更の通知を提供するサービス。

OpsWorks

https://aws.amazon.com/jp/opsworks/

Service Catalog

https://aws.amazon.com/jp/servicecatalog/

Trusted Advisor

https://aws.amazon.com/jp/premiumsupport/trustedadvisor/

Personal Health Dashboard

https://aws.amazon.com/jp/premiumsupport/phd/

セキュリティ、ID、コンプライアンス

Cloud Directory

https://aws.amazon.com/jp/cloud-directory/

Identity and Acces Management (IAM)

IAMにより、ユーザーのAWSサービスおよびリソースへｎアクセスを完全にコントロールすることができる。 AWSのユーザーとグループを作成・管理し、アクセス権を使用してAWSリソースのへのアクセスを許可・拒否できる。

IAMユーザーとそのアクセス管理

IAM内でユーザーを作成し、個別のセキュリティ資格情報(アクセスキー、パスワード、多要素認証デバイス)を割り当てることができる。管理者がユーザーにどの操作の実行を許可するかをコントロールできる。

IAMロールおよびアクセス権限の管理

IAMでロールを作成し、権限を管理することで、そのロールを適用するエンティティまたはAWSサービスの実行可能なオペレーションをコントロールする。

フェデレーティッドユーザーとその権限の管理

IDフェデレーションを有効にすると、社内の既存のアイデンティティ(ユーザー、グループ、ロール)によるAWSマネジメントコンソールへのアクセス、APIの呼び出し、リソースへのアクセスを許可できる。

Inspector

https://aws.amazon.com/jp/inspector/

Certificate Manager

https://aws.amazon.com/jp/certificate-manager/

CloudHSM

https://aws.amazon.com/jp/cloudhsm/

Directory Service

https://aws.amazon.com/jp/directoryservice/

Key Management Service

https://aws.amazon.com/jp/kms/

Organizations

https://aws.amazon.com/jp/organizations/

Shield

https://aws.amazon.com/jp/shield/

WAF

アプリケーションの可用性に影響を与え、セキュリティを侵害し、過度にリソースを消費する可能性のある一般的なウェブの脆弱性からウェブアプリケーションを保護するもの。(Web Application Firewall) どのトラフィックの許可するのか、ブロックするのかを制御できる。ルールを作成し数分以内にデプロイが可能。

分析

Athena

https://aws.amazon.com/jp/athena/

EMR

Hadoop フレームワークで、動的にスケーラブルなEC2インスタンス間で大量のデータを観点、迅速、費用効率よく配布、処理できるサービス。 Apache SparkやHBaseなどといった他の一般的なフレームワークをEMRで実行することが可能。 S3やDynamoDB内のデータも操作することができる。

CloudSearch

https://aws.amazon.com/jp/cloudsearch/

Elasticsearch

Elasticsearch(Elasticsearch社という会社が元々ある)を簡単にデプロイ、運用、スケールし、、ログ分析、全文検索、アプリケーションの監視などを行う。 AWSの他サービスとも統合されているので、未加工データから実践的なインサイトに移ることができる。

Kinesis

https://aws.amazon.com/jp/kinesis/

Redshift

高速で完全マネージド型のペタバイト規模を誇るデータウェアハウス。 1時間あたり0.25USDで利用できる。列指向ストレージ、データ圧縮、ゾーンのマッピングが使用されているので、クエリ実行に必要なI/Oの量が削減される。超並列処理アーキテクチャーが採用されている。コンソールかAPI呼び出しを使用し、データウェアハウスのノードの数やタイプを簡単に変更できる。

QuickSight

https://aws.amazon.com/jp/quicksight/

Data Pipeline

オンプレミスのデータソースと同様に、異なるAWSコンピューティングあストレージサービス間で、指定された間隔で信頼せの高いデータの処理や移動を行うためのサービス。簡単な例として、RDBからRedshiftにデータを投入したい場合などで利用できます。Redshiftのテーブルに合わせて変換と加工を加える役割を果たします。

Glue

https://aws.amazon.com/jp/glue/

人工知能

Lex

https://aws.amazon.com/jp/lex/

Polly

https://aws.amazon.com/jp/polly/

Rekognition

https://aws.amazon.com/jp/rekognition/

Machine Learning

https://aws.amazon.com/jp/machine-learning/

モバイルサービス

Mobile Hub

https://aws.amazon.com/jp/amplify/

Cognito

ウェブアプリなど、ユーザーのサインアップやサインインを簡単に追加する。 FacebookやTwitterなどのソーシャルIDプロバイダー経由で、SAML IDソリューションを使用して、ユーザー認証ができます。

Pinpoint

https://aws.amazon.com/jp/pinpoint/

Device Farm

https://aws.amazon.com/jp/device-farm/

Mobile SDK

https://aws.amazon.com/jp/amplify/

Mobile Analytics

https://aws.amazon.com/jp/mobileanalytics/

アプリケーションサービス

Step Functions

https://aws.amazon.com/jp/step-functions/

API Gateway

簡単にAPIの作成、配布、保守、監視、保護が行えるサービス。トラフィック管理、認可とアクセスコントロール、モニタリング、APIバージョン管理など、最大数十万個の同時API呼び出しの受け入れと処理に伴うタスクを取り扱える。

Elastic Transcoder

https://aws.amazon.com/jp/elastictranscoder/

SWF

https://aws.amazon.com/jp/swf/

メッセージング

SQS

完全マネージド型メッセージキューイングサービス。メッセージを失うことなく、どのような量のデータも転送できる。 AWSの他のサービスが常に利用可能な状況である必要はない。

SNS

完全マネージド型のプッシュ通知サービス。個々のメッセージを送信したり、多数の受信者にメッセージをファンアウトしたりできる。モバイルデバイス/メール受信者にプッシュ通知を送信したり、他の分散サービスにメッセージを送信したりできる。また、Lambda関数やHTTPエンドポイントにもメッセージを配信できる。

SES

https://aws.amazon.com/jp/ses/

ビジネスの生産性

WorkDocs

https://aws.amazon.com/jp/workdocs/

WorkMail

https://aws.amazon.com/jp/workmail/

Chime

https://aws.amazon.com/jp/chime/

デスクトップとアプリケーションのストリーミング

WorkSpaces

https://aws.amazon.com/jp/workspaces/

AppStream 2.0

https://aws.amazon.com/jp/appstream2/

IoT

Greengrass

https://aws.amazon.com/jp/greengrass/

IoT ボタン

https://aws.amazon.com/jp/iotbutton/

ゲーム開発

GameLift

https://aws.amazon.com/jp/gamelift/

Lumberyard

https://aws.amazon.com/jp/lumberyard/

以上.

2018-12-06

【キャリア設計】FIRE とは！？経済独立と早期退職

キャリア設計

こんにちは。

今まで技術的な記事しか投稿していませんでしたが、今回はキャリア設計について思ったことを書いていこうと思います。

といっても、私自身経歴が豊富で優秀ということではありませんので、どういったことを主軸にするかといいますと、

とある頭文字からとったFIREという今アメリカのGEEKな若手の間で話題になっている動きについて考察してみます。

FIREとは？？

FIREとは、「Financial Independence, Retire Early」の頭文字をとったものです。

この意味は、「経済独立、早期退職」という意味です。

先日目にとまって関心があったので、記事に残そうと思いました。

至ってシンプルですね。そして話題となるのであれば、ただ「ニートになろう！」ということではなさそうですｗ

Pete Adeney

Pete Adeneyという現在ブロガーとして生活している方が、このブログで自分の経験を記事にしたのが火種のようです。

www.mrmoneymustache.com

このブログのモットーは、「倹約は解放であり、剥奪ではない」彼は元ソフトウェアエンジニアで奥さんもエンジニアだったそうです。そして、職場は30歳で退職したそうな。では、いったいどういった内容がFIREなのか、どうしてこの動きが話題になっているのかを見ていきましょう。

4%ルール

この動きの中で一番重要なのが、4%ルールというもの。

簡単に言うと、毎年の引き出し額を総資産の4％に抑えるというルールです。

例えば、資産が3,500万円だとすると、140万円を毎年引き出して使うということです。この計算でいくと、25年間もつことになりますね。

もちろん、この総資産を毎年引き出すだけではありません。なんらかの手段で資産を維持していかなければならないということです。

なんか期待し過ぎて、結局「働くのかい！」と思う方もいるのではないでしょうか笑

ただ、この4%ルールを実行することで、総資産を増やしたりすることができる、増やすことができるという言い方より、私は、効率的にストレスなく稼ぐことに注力できるのではないかとかんじました。

では、先人たちは如何にして生活を維持させているのでしょうか？

現実的に考えて

ここからは私の個人的な意見も盛り合わせていきます。

4%ルールは素晴らしいと思いますが、これを日本で現実的に実行できるか考えてみます。

第一人者である、Pete Adeneyさんはインデックスファウンドを運用しているとのこと。

インデックスファンド - Wikipedia

わたしは特に投資に詳しくないので、どれくらいの時間をかけたりお金をかけたりするのかよくわからないですが、投資と聞くと自分の容量で運用できるイメージなので、理にかなっていますね。

また、他のFIREの先人の中には、元ウォールストリートで勤務していた方や、インテルでエンジニアをしていた方などの情報がありました。

んー単純に経歴が素晴らし過ぎて実感が湧かない...

ただ、趣味をそのまま稼ぎにしている方も多いそうです。

そこに焦点をあてます。

エンジニアだとしたら、友人と組んで何かプラットフォームを作成したり、Webアプリやスマホのゲームなどを作成して収入を得るということも考えられますね。サーバーの運用費はそのまま4%ルールを適用すれば、コスト面も考慮しながら開発できます。

また、アクセサリーをつくって販売とかでもいいですね。ハンドメイドの作品を販売できるサービスもすでに存在します。

これらのことって、今の時代だからこそできることなのではないでしょうか！

このFIREの動きは、この時代だからこそ必然的に起こったのでは？とも考えられます。

もう少し具体的に数字を元にして考えてみましょう。

より具体的に

(※ ちょっとググっただけなので、本当に正確な数字でないことはご承知下さい。)

東京都の平均年収を調べました。

厚生労働省発表の「賃金構造基本統計調査」によると、約615万でした。これは、平均年齢42歳、平均勤続年数12.2年ということです。

大体30歳までにリタイアということを考えると、年収600万を超える人は稀でしょう。

若手、大体20歳〜29歳でいうと、250〜400万くらいでしょうか。

上記の例で出した3500万円の資産をつくろうとしたとして、この平均年収を元にFIREを実現しようとすると、どういう計算になるでしょう。

かなり数字を大雑把で計算しますｗ

例: 年収350万 (内ボーナス60万、基本給額面24万) (=月々手取り19万) 一人暮らしの費用: 家賃6万、光熱費1万、食費2万、定期代1万、ケータイ/ネット代1万 (=計11万)

この年収が毎年ということではないでしょうが、これを元にすると、月々の余りは、約8万円といったところでしょうか。個人差で、交際費やもっとここ抑えられるといったところもあるでしょうが、ここではこの数字だとします。

この8万円を毎月貯蓄し、ボーナスを全額貯蓄したとすると、約155万円を毎年貯蓄できる計算です。これで3,500万を貯めようとすると、約22年ほどかかりますww

これでは既に定年退職のほうが近いということになってしまいますね笑

Pete Adeneyさんは、奥さんと各750万円を稼ぎ、無駄遣いを一切やめて家を購入してリタイアしたそうです。確かに、二人でと考えると現実的な数字になってきそうです。

単純に350万×2=700万円で、単純に費用が2倍かかるとして毎年310万円貯蓄できるとすると、約11年で3,500万円に到達します。

確かにちょっとは現実的な数字になってきましたね。

これを調べているときに面白い統計を見つけました。日本における子供を出産〜大学にあげるまでの養育費をまとめたサイトです。

一人の子どもの出産から大学卒業までの総費用 : 関連資料 : 子ども応援便り

これによると大体3,000万円/1人くらいでしょうか。総資産3,500万円だとしても子供1人育てる養育費で消えてしまうので、やはり総資産の維持は重要なようです。

さて、計算はかなり大雑把でしたが、具体的に考えてみたところでかなり実現するには難易度が高いようにも思います。

ですが、ここでようやくこの記事の大事なところです笑

自由だからこそ

Pete Adeneyさんは優秀でお金を稼げるからFIREを実行したというわけではないということです。毎日同じ職場、同じ時間に出勤し、同じ顔を見て仕事をするというライフスタイルを、自分のしたいようにするにはどうしたらいいかを考えた結果なのではないでしょうか。

アメリカではエンジニアの地位が高いです。日本では真逆なかんじですね笑でも、国内ばかりみていては、一向に先が見えないままです。エンジニア(デベロッパー)やプログラマーというのは、皆さんが毎日使用してるといっていいシステムなどを開発し、日々イノベーションを起こす職業でもあります。YouTuberのように、好きなことで生きていくというわけではないですが、また違った側面から新しい働き方を提案&実行できる人たちでもあるような気がします。

また、どんどん国内におけるルーティング作業はコンピュータやロボットに代替されていき、より市場で自分の価値を証明していくことが困難になっていくのではないかとも思います。

FIREという動きも日本国内では、また違ったかたちで実現できるかもしれませんね。

以上.

2018-11-28

【Python】Djangoのsettings.pyって2回読み込まれてる!!???

Python Django

今回は、Djangoのプロジェクトでちょっとハマったことがメインです。 ※ 日本語の記事なくて、結果ですが断定して言えないのでご承知下さい！

経緯

Djangoのプロジェクトでローカル環境開発をしていました。前回少し記事にしたやつですね。

o21o21.hatenablog.jp

こちらけっこうイジっていて、DBの設定を見直していたところ、 環境毎の切り替えが必要やん！って思って調べていました。

できるだけプロジェクト構成はシンプルにしたいので、settings.py内で収めようとしました。

環境変数を使用して、環境ごとにDBの設定を変更しようと、以下のようなかんじになりました。

SET_DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'xxx',
        'USER': 'xxxx',
        'PASSWORD': 'pwd',
        'HOST': 'db',
        'PORT': 3306,
    },
    'staging': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'xxx',
        'USER': 'xxxx',
        'PASSWORD': 'pwd',
        'HOST': 'db',
        'PORT': 3306,
    }
}

env = os.environ.get('DJANGO_ENV', 'default')
print('Running on "{}".'.format(env))

if env in SET_DATABASES:
    DATABASES = SET_DATABASES[env]
else:
    print('ERROR: Unknown environment for database settings.')

ちょっとif文があるけど、まあこれくらいならいいかと思い、そのままdocker-compose upで立ち上げ。

するとそんなすんなりいきませんでした。

エラー

...略...

if self._databases[DEFAULT_DB_ALIAS] == {}:
KeyError: 'default'

...略...
 django.db.utils.ConnectionDoesNotExist: The connection default doesn't exist

ん、なんかdefaultがないって言われている... でもdefaultも記述してあるなあ〜と思ってログを見てみました。

そしたらなんかsettings.pyが2回読み込まれてる疑惑が浮上。

ログのなかでprintしている内容が2回実行されていたのです。

なんだろうと思いながら調べてみると、以下の質問を発見。

stackoverflow.com

結果的に...

結果的にこの質問からすると、Djangoの起動時には、プロセスが2回別々で起動され、settings.pyが読み込まれてるらしい。 (ちょっと細かいことは調べてないです。。。)

なるほど〜、ここが大きく関係していそうだな〜

ということでした。

あんまりsettings.pyにはゴチャゴチャコード書かない方が良さそうでした。。

なので、settings.pyをちょっとファイル名を変更してもう1ファイル作成し、起動時のsettings.py自体の読込を環境ごとに変更する方法を検討しようかと思います。

以上.

2018-11-19

【Docker】Django + REST framework + mysql with docker-compose

Django docker-compose docker Python Python3 MySQL

今回は、DjangoのREST frameworkのローカル環境に挑戦してみました。

初めてPythonのフレームワークを触るので、浅はかなところもあるかと思いますがご了承下さい！

ゴールは、ブランチでこれが表示されるところまでいきます。

f:id:o21o21:20181119195642p:plain

docker-composeを使用するので、インストールしてない方はインストールしましょう。この記事ではインストールの説明は割愛します。(「docker for mac インストール」で検索すれば出てくると思います。)

さて、さっそく取り掛かっていきます。

※ 私の環境は、macOS

作業場作成

適当に今回のプロジェクトを作成するディレクトリに移動します。

$ cd /path/to/project
or
$ mkdir project_name

任意ですが、一応README.mdを作成。

初期データ、ディレクトリ作成

今回、DB(mysql)と接続するために、初期データを置いておく必要があります。

$ mkdir mysql
$ cd mysql
$ mkdir init

上記を作成して、mysql/init/というディレクトリを作成します。このディレクトリ配下に、.sqlをファイルを置いて置きます。

※ この.sqlファイルですが、既存の運用で使用されているDBのdumpファイルでも可能です。ちょっと試したいというかたは、テーブルを作成するsql文などを適当に記述してもOKです。

ここまでのプロジェクト構成は以下です。

<project_name>
├── README.md
├── mysql
│   └── init
│      └── test.sql

主要なファイルを作成

次にDockerfileとdocker-compose.ymlをプロジェクトディレクトリで作成します。

$ touch Dockerfile
$ touch docker-compose.yml

重要なのは、この2つのファイルの記述です。

Dockerfile

FROM python:3.5

ENV PYTHONUNBUFFERED 1

RUN mkdir /code

WORKDIR /code

# install Libraries
COPY requirements.txt /code/
RUN pip install -r requirements.txt

# to be consistent versions of between "Django and PyMySQL"
RUN pip install -U PyMySQL

ADD . /code/

docker-compose.yml

version: '3.0'
services:
  db:
    image: "mysql:latest"
    container_name: <container_name>
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_DATABASE: <db_name>
      MYSQL_ROOT_PASSWORD: <db_root_pwd>
      MYSQL_USER: <db_user>
      MYSQL_PASSWORD: <db_pwd>
    ports:
      - 3306:3306
    volumes:
      - type: bind
        # source: ./docker/db/init.sql
        source: ./mysql/init/<file_name>.sql
        target: /docker-entrypoint-initdb.d/<file_name>.sql
      - type: bind
        source: /tmp/docker/tmpdata
        target: /tmp/tmpdata
  web:
    container_name: <container_name>
    build: .
    command: python manage.py runserver 0.0.0.0:8080
    volumes:
      - .:/code
    ports:
      - 8080:8080
    environment:
      DJANGO_SECRET_KEY: $DJANGO_SECRET_KEY
      DJANGO_DEBUBG: $DJANGO_DEBUBG
    depends_on:
      - db

ほとんど公式と同じ記述です。ただ、公式では、PostgreSqlの場合ですし、先程作成したDBの記述はありません。シンプルに詳細を確認したい人は、一読するといいと思います！

クイックスタート・ガイド：Docker Compose と Django — Docker-docs-ja 17.06.Beta ドキュメント

Dockerfile

こちらはシンプルですね。python ^3.5をベースにpipでrequirements.txtを元にライブラリをインストールさせています。ここで一番注目したいのは、PyMySQLのアップグレードです。

私が環境構築をしている時に、何時間もつまったのがこれ。なんてことないエラーでしたが、どうもうまくいかなかった...

知っていればなんてことないことなのですが、どうやらDjangoのversionが2.0以上になって発生するエラーのようでした。色々ググってみると、色んなやり方で解決されているみたいでしたが、アップグレード1発で解決されるのが一番シンプルですよね！

docker-compose.yml

こちらもいたって普通の記述です。初期データを必要とすることで、volumesの設定(特にtarget)が重要です。

docker-entrypoint-initdb.dに注目します。これは、mysqlのイメージがコンテナの起動時に自動的に初期データを読み込んでくれる機能を使用しています。

下のbindは、初期データがなかった場合に代用できる記述です。

ここまで作成して、足りないファイルが2つあります。

requirements.txt

このプロジェクトで必要なPythonのライブラリを記述します。

Django==2.1.1
djangorestframework
django-filter
psycopg2
psycopg2-binary

.env

docker-compose.ymlで使用されている変数があると思います。($DJANGO_SECRET_KEY) これは、Djangoのプロジェクト作成時に発行されるキーなのですが、環境変数に設定しようかと思って普通に記述すると、以下のエラーが発生。 (何故環境変数に、DjangoのSECRET_KEYを設定しようと思ったかというと、毎回毎回Docker環境を作成しては削除していると、Githubでのヴァージョン管理の際に、settings.pyは管理したいけど、SECRET_KEYは別で管理したいということになりました。)

ERROR: Invalid interpolation format for "environment" option in service "web": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

どうやらエスケープしなければならない記号が入っていて、environmentに直接値を記述できませんでした。(やり方はあるが面倒くさい..w) なので、.envというファイルを作成し、これをヴァージョン管理。

え、ヴァージョン管理するの？って思うかもしれませんが、これには理由があります。 1つ目としては、他の人に同じ.envを提供できる。(= 同様な環境構築を目指す。)また、開発環境においては他の値で代用できたりしますね。 2つ目は、STGや本番では、OSの環境変数を見に行くので大丈夫ということ。ただし、これはあくまで、本番サーバーでDockerを稼働させないことになります。まあ、とりあえずローカル環境はDockerで！みたいな人向けになってしまいますが...(でも会社とかで作業していると、新機能作成で本番はDockerじゃないけど、機能追加のためにDocker流行ってるし今回のローカル環境はDockerにしよう！って人も多いのでは？ｗ)

それはさておき、.envには以下を記述

DJANGO_SECRET_KEY=-<今は適当な値をとりあえずいれておく>
DJANGO_DEBUBG=True

ProjectとAppを作成

コマンドを実行してプロジェクトとアプリを作成します。

プロジェクトルートにて、以下を実行。

# プロジェクトを作成
$ docker-compose run web django-admin.py startproject settings .

# アプリケーションを作成
$ docker-compose run web python manage.py startapp src

これを実行すると、プロジェクト構成は以下のようになるかと思います。

<project_name>
├── Dockerfile
├── README.md
├── db.sqlite3
├── docker-compose.yml
├── manage.py
├── mysql
│   └── init
│       └── <file_name>.sql
├── requirements.txt
├── settings
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-35.pyc
│   │   ├── settings.cpython-35.pyc
│   │   ├── urls.cpython-35.pyc
│   │   └── wsgi.cpython-35.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── src
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── migrations
    │   └── __init__.py
    ├── models.py
    ├── tests.py
    └── views.py

一気にファイルやらディレクトリが作成されたかと思います。今回、プロジェクトとアプリの作成コマンドの名前をsettingsとsrcにしました。これは任意です。ディレクトリ名としてわかりやすいものでいいと思います。

mysqlとの接続

/settings/settings.pyを編集します。

DBの設定

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql,
        'NAME': <db_name>,
        'USER': '<user_name>,
        'HOST': 'db',
        'PORT': 3306,
    }
}

PyMySqlの読込同ファイル、任意の箇所に以下を記述

import pymysql

pymysql.install_as_MySQLdb()

また、このファイルにSECRET_KEYが記述されているかと思います。この値を.envのDJANGO_SECRET_KEYに追記し、 settings.pyのSECRET_KEYの部分に、os.environ.get('DJANGO_SECRET_KEY')を代わりに書いて、OSの環境変数を参照するようにします。

合わせて、DEBUGもos.environ.get('DJANGO_DEBUBG')として書き換えます。

その他、プロジェクトに合わせて、LANGUAGE_CODEとTIME_ZONEも合わせます。 (体外が、jaとAsia/Tokyoでしょうか。)

INSTALLED_APPSにもこちらを追記します。'rest_framework'

マイグレーション

DBとのシンクのために、マイグレーションファイルを作成します。

models.pyに対象のテーブル(class)を記載して実行すると、src/migrations/ディレクトリが作成され、 0001_initial.pyのようなファイルが作成されます。はじめにmodels.pyが空の状態でmigrateをしても大丈夫ですが、src/migrations/配下にはini.pyしか作成されません。

# ホストからマイグレーションファイルををDBに適用
$ docker-compose exec web python manage.py makemigrations

# Dockerコンテナの中に入ってマイグレーションファイルをDBに適用
$ python manage.py makemigrations

# ホストからmodels.pyに書いたclassを読み込んでマイグレーションファイルを作成
$ docker-compose exec web python manage.py makemigrations <app_name>

# models.pyに書いたclassを読み込んでマイグレーションファイルを作成
$ python manage.py makemigrations <app_name>

ググってみるとほとんど記事が新規でお試しテーブルみたいなかんじでmodels.pyに記述していますが、既存のdumpファイルから作成されたDBから以下のコマンドで、models.pyに自動でclassを作成してくれます。

$ python manage.py inspectdb tabbel_name >> models.py

実行

最後に実行です。

$ docker-compose up

.
.
.
<container_name> | You have 15 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
<container_name> | Run 'python manage.py migrate' to apply them.
<container_name> | November 19, 2018 - 19:51:55
<container_name> | Django version 2.1.1, using settings 'settings.settings'
<container_name> | Starting development server at http://0.0.0.0:8080/
<container_name> | Quit the server with CONTROL-C.

このような出力されればOKでしょう。

http://localhost:8080/

ブラウザでlocalhostにアクセスし、Welcomeページが表示されていれば、あとはもう開発を開始できます！

まとめ

だいぶ駆け足で書きました。うまくいかない場合は、もちろん公式を参照してみて下さい。

確認としては、Dockerのコンテナにはいることで解消できる場合もあります。($ docker exec -i -t コンテナ名 bash) また、Dockerのコンテナは何度削除しても大丈夫です！($ docker rm <CONTAINER ID or NAMES>)

1からのやり直しも簡単にできるのはDockerのいいところでもあるのかなと思います。今回私は、初期データとして、5GBのdumpファイルを用いましたが(ちょっと最初のイメージコンテナ作成時時間はかかりますが、)問題なく動作しています。

後先考えると環境構築はほんとに大変... ですが、とりあえず構築させていくことが大事ですね！

以上.

2018-11-05

【Go】簡単！使い捨て、GoのDocker開発環境を構築

GO GO言語 golang docker docker-compose

以前は、macOSでのGoのプロジェクトについて考えました。

o21o21.hatenablog.jp

今回はGo (golang)のDocker開発環境を考えてみます。拡張性を意識して、docker-composeを利用してみます。

※ ヴァージョンの関係で1発でうまくいかない場合もあります。分かり次第更新します！(2019/02/22更新、下部記載)

想定として、なる早で環境構築し、GoのWebアプリを開発していこう！みたいなノリです。ちなみに、Goのフレームワークとして、echoをインストールしていきます。ゴールは、ブラウザでのHello Worldを目指します。

私の環境は、macOSです。事前にDocker (macならDocker for macをインストールしましょう！)

さて、順をおってみていきましょう！

プロジェクトの作成

今回、Dockerなので特にホストOS(私ならmac)のGOPATHを意識する必要はありません。 (Docker上でのGOPATHは指定します。) 気になる方は、この記事の冒頭であげた過去の記事を参考にしてみて下さい。

なので、任意のディレクトリに新規プロジェクトを作成しましょう。

必要なファイルを作成

コマンド docker-compose upで起動させるために、必要な設定ファイルを新規作成します。この記事では必要最低限の記述にします。portの指定などご自身のやりたいことに合わせて設定してみて下さい。 ※ 自分の使用しているdocker及びdocker-composeのversionにも注目！

Dockerfile

FROM golang:latest                                                                                                                                                                                    
  
WORKDIR /go/src/go-app2
COPY . .
    
# "Go" Environment variable
ENV GO111MODULE=on
    
# install Go web framework
RUN go get -u github.com/labstack/echo
   
# install "Fresh" restart tool
RUN go get github.com/pilu/fresh

CMD ["fresh"]

上からみていきます。

goのヴァージョンは最新のものを取得しにいってます。(ヴァージョン指定も勿論可能)

GO111MODULEというGOの環境変数をonに設定します。これでモジュールを自動的に読み込むことができます。

これをDockerfileに記述しないと、docker-compose upした時に以下のWARNINGが出ました。

go get: warning: modules disabled by GO111MODULE=auto in GOPATH/src;
    ignoring go.mod;
    see 'go help modules'

GO111MODULEを記述した際に、プロジェクトディレクトリに自動的にgo.modというファイルが作成されます。 (= 今回のプロジェクトに依存したgo.modファイルが生成される。)

そして、フレームワークのechoとホットリロードをするためのFreshをgo getでインストールします。 go getを使用するということは、今回作成されるDocker上には、複数のプロジェクトを共存させる目的ではないことを覚えておいて下さい。仮に、go getをすると、GOPATH配下にインストールされて2つ目以降のパッケージの依存関係を管理しにくくなるからです。 (goから離れていたので、間違ってたらごめんなさい...!!!!)

GO111MODULE

さきほど定義した環境変数GO111MODULEについてです。こちらヴァージョン1.11から追加された、モジュール管理モードの環境変数です。(正式リリースは、1.12かららしい)

on : モジュール対応モード off : GOPATH モード(今まで通り) auto : GOPATH以外のみモジュールモード

今までdepなどを使用していたと思いますが、これは便利！ depからの乗り換えも楽みたいですね！

ちなみに、今回のDocker環境で開発中に新しいモジュールを追加すると、freshが検知し自動的にモジュールがインストールされます。そうすると、go.modに require package/name v1.1x.2x のように追記されていることが確認できました。また、go.sumファイルも生成されます。これは、モジュールの依存関係を示すファイルのようです。

そして最後にコマンド実行です。

ホットリロードについてですが、どういうことかというとコンパイル不要な言語ならいいのですが、一旦コンパイルしてから動作させる言語において、よくDockerで起動させられたけど、ファイルの編集をした際にもう一度docker runとかしないといけない...ということが起こります。

かなり面倒なので、タスクランナー的なものが必要です。厳密に今回使用するFreshはタスクランナーとは書いてないようですが、要はファイルを監視し変更が検知されると、自動的にrestartしてくれるものです。

なので、Dockerfileでは、最後にfreshというコマンドで起動させます。

Freshについては、以下の公式を参照してみて下さい。 Fresh自体の設定ファイルも作成できるようです。

github.com

docker-compose.yml

続いてdocker-compose.ymlですが、そんなに記述がないので説明を割愛します。

   version: '3'                                                                                                                                                                                        
   services:
     app:
       build: .
       container_name: <projecrt_name>
       volumes:
         - ./:/go/src/<project_name>
       ports:
         - "8080:8080"
      environment:
          GO111MODULE: "on"

ここまで作成できれば、ほぼ完成です。 Dockerfileを基に、1つのコンテナと1つのイメージが作成されるはずです。(golangのイメージ含めるなら2つかな？)

あとは適当にmain.goを作成します。

goファイル

main.go

package main

import (
    "log"
    "net/http"
    "path/filepath"
    "sync"
    "text/template"
)

type templateHandler struct {
    once     sync.Once
    filename string
    templ    *template.Template
}

func (t *templateHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    t.once.Do(func() {
        t.templ = template.Must(template.ParseFiles(filepath.Join("templates", t.filename)))
    })
    t.templ.Execute(w, nil)
}

func main() {
    http.Handle("/", &templateHandler{filename: "top.html"})

    if err := http.ListenAndServe(":8080", nil); err != nil {
        log.Fatal("ListenAndServe", err)
    }
}

templates/top.html

<p>Hellooooooooooooooooo World!!!!!!!!!!!!!!</p>

実行

いざ実行です！

$ docker-compose up
Building app
Step 1/7 : FROM golang:latest
 ---> d817ad5b9beb
Step 2/7 : WORKDIR /go/src/go-app2
Removing intermediate container 816a33af9a01
 ---> bb3d6012e557
Step 3/7 : COPY . .
 ---> e38c75d754d3
Step 4/7 : ENV GO111MODULE=on
 ---> Running in 57345b25fb4f
Removing intermediate container 57345b25fb4f
 ---> d9500cf1f5cd
Step 5/7 : RUN go get -u github.com/labstack/echo
 ---> Running in 01dc8d6ebd6c
go: finding github.com/labstack/echo v3.2.2+incompatible
go: downloading github.com/labstack/echo v3.2.2+incompatible
go: finding github.com/labstack/gommon/log latest
go: finding github.com/labstack/gommon/color latest

... 略 

Creating goapp2_app_1 ... done
Attaching to goapp2_app_1
app_1  | 11:2:58 runner      | InitFolders
app_1  | 11:2:58 runner      | mkdir ./tmp
app_1  | 11:2:58 runner      | mkdir ./tmp: file exists
app_1  | 11:2:58 watcher     | Watching .
app_1  | 11:2:58 watcher     | Watching templates
app_1  | 11:2:58 main        | Waiting (loop 1)...
app_1  | 11:2:58 main        | receiving first event /
app_1  | 11:2:58 main        | sleeping for 600 milliseconds
app_1  | 11:2:59 main        | flushing events
app_1  | 11:2:59 main        | Started! (8 Goroutines)
app_1  | 11:2:59 main        | remove tmp/runner-build-errors.log: no such file or directory
app_1  | 11:2:59 build       | Building...
app_1  | 11:3:00 runner      | Running...

あとは、ブラウザでアクセス。

http://localhost:8080/

htmlの内容が表示されていたら成功です。

また、docker-composeを起動したまま編集してみましょう！リロードし、変更が反映されていたら大丈夫です。

Dockerコンテナの中へ

以下のコマンドでDockerコンテナの中に入って、ローカルとのファイルのシンクがされているか確認できます。

$ docker exec -i -t <container_name> bash

今回の例だと、ディレクトリ /go/src/<project_name>が存在し、 $GOPATHは、/goになっていることが確認できます。

まとめ

いつもホットリロードに悩まされていましたが、Freshは楽ですね！他にもGoのプロジェクトで使用されているタスクランナーがあります。

github.com

※~~少しdockerで個人的に気になることがあるので、解決したら更新します！~~

トラブルシューティング

私が試したことしか記載できませんが、以下で1発でブラウザ確認までいけました。

go.modファイル作成(空でおｋ)
goのヴァージョンを確認

私の場合、1.12系で大丈夫でした。他のヴァージョンは試してないのでわかりません。。

FROM golang:1.12-rc

go.modファイル作成の理由としては、GO111MODULE=onにしているとgo.modファイルが設置されているディレクトリでのみgo getコマンドが実行できないためです。

以上.

Nginx

概要

設定ファイル概要

C10K問題

確認

インストールできるjavaを確認

インストール

有効化

AWS ホワイトペーパー (概要)

クラウドコンピューティングとは？

クラウドコンピューティング6つの長所

クラウドコンピューティングのタイプ

クラウドコンピューティングのモデル

クラウドコンピューティングのデプロイモデル

グローバルインフラストラクチャ

セキュリティとコンプライアンス

セキュリティ

AWSプラットフォーム

AWSマネジメントコンソール

AWSコマンドラインインターフェース

Software Development Kits

コンピューティング

EC2

インスタンスタイプについて

EC2 Container Service (ECS)

EC2 Container Registry (ECR)

Amazon Lightsail

AWS Batch

Elastic Beanstalk (EB)

Lambda

Auto Scaling

ストレージ

S3

EBS

Elastic File System (EFS)

Glacier

Storage Gateway

データベース

Aurora

RDS

DynamoDB

ElastiCache

移行

Database Migration Service

Server Migration Service

Snowball

Snowball Edge

Snowmobile

ネットワーキングとコンテンツ配信

CloudFront

Route 53

Direct Connect

Elastic Load Balancing (ELB)

開発者ツール

CodeCommit

CodeBuild

CodeDeploy

CodePipeline

管理ツール

CloudWatch

EC2 Systems Manager

CloudFormation

CloudTrail

Config

OpsWorks

Service Catalog

Trusted Advisor

Personal Health Dashboard

セキュリティ、ID、コンプライアンス

Cloud Directory

Identity and Acces Management (IAM)

Inspector

Certificate Manager

CloudHSM

Directory Service

Key Management Service

Organizations

Shield

WAF

分析

AWS コマンドラインインターフェース