helloworlds

not a noun, it's a verb

【インフラ】気になるLinuxコマンド!

今回はLinuxのコマンドについて色々調べてみました。

自分の場合、仕事でもプライベートでもだいたい同じコマンドを使っていますが、 作業中に「もっと便利にならないかな?」とか効率化を求めます。

が、その時は思っていてもすぐ忘れていて、新しいコマンドを一時的にしか覚えられない....

ということで、サーバーサイド、インフラエンジニアがよく使うコマンド!みたいなかんじで調べてまとめようかと思います。 (完全あとで見直す用になりそうw そして、随時更新していきます ############)

コマンドって一体どれくらいあるの??

一度は考えてしまうと思いますw 一体この世の中には何種類のコマンドが存在するのか?

この疑問を解決するには、まず種類分けをしなければならなそうです。 例えば、UNIX系なのか、とかとか... ちょっと調べましたが中々統計データは出てこなかったのでわかりませんでした。

これはLinuxで使用されるコマンド集。

fossbytes.com

これだけでも膨大な量ですねw また、AWScliとかWindowsコマンドとかたくさんあるので、調べようがない... 日本人の方でコマンド集を随時更新されている方がいましたが、そこではコマンドの種類問わず、約500のコマンドが記載されていました。

なので、ここでは主にLinuxで用意されているコマンドをみていきます。

また、"どうしてコマンドが使用できるのか"など、その仕組については割愛します。 以下の記事がわかりやすいので、載せておきます。

シェルの概念と機能

もしなんの種類のシェルを使用しているのかわからない方は以下を実行してみましょう!

$ echo $SHELL

基礎

ps

Linux上で動作しているプロセス (process)を確認するコマンド。 コマンドの話ではないですが、私なんかは自宅のWindowsデスクトップを使用しているとき、 セカンドディスプレイで必ずタスクマネージャーを表示させています。 GUIがなくてももちろんプロセスは確認しないといけませんね!

これでプロセスを確認。(オプションなしでも使用できる)

$ ps
$ ps auxwwf 
$ ps rlu
$ ps auxwwrlue
オプション 内容
-A 全プロセスを表示する。
a 端末操作のプロセスを表示
x 端末操作以外のプロセスを表示
r 現在、実行しているプロセスを表示
c 実行しているコマンド名を表示
e 実行しているコマンド名と環境変数を表示
u CPUやメモリの使用率なども表示
h 項目名を表示しない
l プロセスの状態なども表示
f プロセスを階層で表示
o 指定したリスト順の出力形式で表示
-C 実行しているプロセスやプログラムのファイル名を指定
-u プロセスを実行しているユーザーを指定
-g プロセスを実行しているグループを指定
-p 実行しているプロセスのプロセス番号(PID)を指定
--sort プロセスの表示順を指定
w 出力時の幅を広げる

よく使用されるオプションとして、fがあるようだけど、なんとmacでは使用できない。 オプションfは、プロセスを階層で表示するためのオプション。 そのかわりに、pstree コマンドが使用できるようです。

$ brew install pstree
$ pstree

pstreeをオプションなしで実行すると、ものすごい勢いでツリーが表示されてしまいますw なので、パイプをあわせて使用したほうが良さそうです。

$ pstree | grep root

どうしてツリー表示がいいかというと、子プロセスをkillしても問題が解決しない場合があって、親のプロセスをおう必要があるからです。

psコマンドはここまでにして、リアルタイムでプロセスを確認する手段もあります。

top

topコマンドは、実行中プロセスの情報をリアルタイムで確認できるコマンドです。

オプションなしで実行できます。

$ top
$ top -u <user_name> # ユーザーを指定
$ top -p <process_id> # プロセスIDはを指定
$ top -d 1 # 表示間隔を1秒にする

少しだけ覚えることがあります。 プロセスが表示されている時に操作することができるので、その操作を知っておくと便利かもしれません。

キー 内容
k 指定したPIDを終了する
r 指定したPIDのNIを変更する
l, t, m 画面上部に表示されている情報の表示/非表示を切り替え
z 画面上の文字に色をつけて強調表示
Shift+V プロセスの一覧をツリー状に表示
Shift+P プロセスの一覧をCPUの使用率が高い順に並べ替え
Shift+M プロセスの一覧をメモリの使用率が高い順に並べ替え
Shift+T プロセスの一覧を稼働時間が長い順に並べ替え

NI(ナイス値)とは、プロセスの優先度を示す数値のこと。-20〜+20で、-20が最も高い優先度になる。

macの場合操作がうまくいかないことがありました。 その場合は(例: CPU使用率順)、top -o cpuでtopコマンドを実行するか、 起動後、o > cpu > Enterでソートできました。 ちなみに、AmazonLinuxでは上記の表で操作できました。

あくまで私の場合ですが、macbook Pro(Core i7, メモリ16GB)で随時起動させていて、他のアプリが重くなるなどの事象は起きないくらいです。 そして、気づいたですが、表示されているプロセスの件数は、画面の大きさに依存するようです。スクロールできないので、たくさん表示させる必要がある場合はウィンドウを広げたほうが良さそうです。

vmstat (vm_stat)

topコマンドがあるのに、vmstatを使用する場合とはどういうことなのでしょうか。 vmstatは、主に仮想メモリやCPU、ディスクI/Oの情報などを確認します。私の理解が正しければ、I/Oに注目すると良いかもしれません。

このコマンドはオプションの使用で、最短1秒での情報を随時確認できます。

$ vmstat
$ vmstat 1       # 1秒間隔で表示 (1行目は、最後に起動した時からvmstatコマンド実行開始までの統計情報を表示)
$ vmstat 1 10  # 1秒間隔で10回表示 
# 出力例

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 1015184 695248 754740    0    0     0   206    0    1  8  2 90  0  0   
 0  0      0 1015292 695248 754740    0    0     0     0   48   44  0  0 100  0  0  
 0  0      0 1015292 695248 754740    0    0     0     0   31   38  0  0 100  0  0  
内容
procs r 実行中と実行待ち中のプロセス数合計
b 割り込み不可能なsleep状態にあるプロセス数
memory swpd 使用中の仮想メモリの量
free 空きメモリの量
buff バッファとして使用しているメモリの量
cache cacheに使用している量
inact アクティブではないメモリの量
active アクティブなメモリの量
swap si ディスクからスワップインしているメモリの量
so スワップアウトしている量
io bi HDDのようなブロック型デバイスから受け取ったブロック数
bo ブロック型デバイスに送ったブロック数
system in 1秒当たりの割り込み回数
cs コンテクストスイッチの回数
cpu us カーネルコード以外の実行に使用した時間(プログラムが動いていた時間)
sy カーネルコードの実行に使用した時間
id 空転していたアイドル時間
wa I/O待ち時間
st ゲストOSがリソース要求を行い、CPUリソースを割り当てがなかった時間の割合

r(実行中/実行待ち)の値がずーっとある場合処理が追いついていないなどが考えられる。 それと同時にswapのsi/soも確認する。できるだけここの値は0になることが好ましい。

このコマンドも運用で頻繁に使用していることが好ましいかもしれない。項目をみれば理解できるが、アプリエンジニアがちょっと見ただけでは、サーバーのスペックだったり、負荷のかかる時間帯だったり、色々とタイミングがあるので、ちょっとずつ観察していくのが良いかもしれない。

I/Oについてはこちらに詳しく載っているので、あとで確認してみるといいかもしれない。

netstat

netstat(Network statistics)とは、ネットワーク接続やルーティングの状況などの状態を出力します。

TCPおよびUDPプロトコルを対象に統計情報を出力するので、ネットワーク系、例えばLISTENしているportの確認や、 意図しない通信をしていないかなどを確認することができます。 インフラの構築のときなど、どのportが待ち受けているかなど便利かもしれません。

$ netstat -lt    # TCPプロトコルで、LISTEN中(待ち受け中)のソケットを確認
$ netstat -an | grep LISTEN  # アクティブなソケットでホストやユーザーの名前解決せずそのまま表示してgrepに渡す

| | 内容 | |-A |接続状態を表示するアドレスファミリを指定| |-I |指定したNICの情報のみ表示(ex. -Ieth0)| |-a| 全てのアクティブなソケットを表示| |-c| 1秒ごとに更新しつつ表示| |-e| 詳細情報を表示| |-g | IPv4IPv6マルチキャストグループメンバーシップ情報を表示| |-i |全てのNICの状態テーブルを表示| |-l |接続待ち(LISTEN)状態にあるソケットのみ表示| |-n| ホストやユーザーの名前解決を行わず数字のまま出力| |-o| ネットワーキングタイマーの情報を出力| |-p| ソケットが属すプログラムのPIDとプロセス名を表示| |-r| ルーティングテーブルを表示| |-s| 各プロトコルの統計情報を表示| |-t| TCPソケットを表示| |-u| UDPソケットを表示| |-v| 詳細な情報を表示|

tcpdump

tcpdumpとは、ネットワークインターフェースを通るパケットのヘッダ情報を出力するコマンドです。

AmazonLinux1にはデフォルトでインストールされていなかったので、yum install tcpdumpですぐインストールできます。

このコマンドは、ネットワーク機器の間の通信内容を取得し、正常なパケットが送受信されているかどうかを確認します。リバースプロキシの設定をしていて、ぶら下がっているサーバー(ソフトインストール前とか)に対して、本当に通信されているかどうかなども確認できます。笑

ネットワークトラフィックをダンプする。膨大に流れているパケットを適切にフィルターして使用する必要がある。 Wikipediaで紹介されている言い方だと、計算機ネットワーク調査ツールと呼ばれるものの一種である。 Windowsには、Windumpというコマンドが用意されていて、Windows上でtcpdumpを動かせるようにしたもの。 基本的にスーパーユーザーになる必要がある。理由として、プロミス・キャストモードを利用するためである。

  • プロミス キャストモードとは

プロミスとは「無差別の」という意味で、自分宛のパケットでない信号も取り込んで処理するということを示す。 主な使用目的としては、適切なルーティングがなされているか、デバッグなどである

オプションが多いので、ぜひこちらの表を参考にしてみてください。

【tcpdump】ネットワークトラフィックをダンプ出力する | 日経 xTECH(クロステック)

ここでは、使えそうなオプションで例を書いてみます。

# インターフェイスを指定して
$ tcpdump -i eth0

# ホストを指定
$ tcpdump host <IP/Host_name>

# (Hostと)ポート番号を指定して
$ tcpdump port 8080
$ tcpdump host 192.168.0.1 and(or) port 80

# 発信(dst)/受信(src)で絞る
$ tcpdump dst port 80
$ tcpdump src port 80

その他、こちらの記事を参考にしてみてください。

参考

【tmux】tmux入門 (mac)

今回はtmuxについて記事を書きました。

私的なことを言うと、最近インフラよりの知見を貯めているからです!w

それはそうと、以前からtmuxについては、名前くらいしか知りませんでした。 (というか、この記事を書いているときもtmux歴まだ1ヶ月も経たないくらいです...w)

なので、入門として読んでくださると助かります!

「これからtmux使ってみよう!」

とか、

「基本設定ってどんなかんじになるうだ?」 など、疑問に思っている方向けになります。

では、さっそく基本情報から見ていきます。

※筆者のOSは、OS Xです。

概要

tmuxとは?と、まず思うことでしょう。何ができるのか?などなど...

tmuxとは、 ターミナルマルチプレクサです。 (※できるだけ個人の解釈でなく、公式の文を引用します。)

マルチプレクサとは、簡単に言うと、複数の信号を1つの信号として出力することです。 これは電子回路系のお話なので、もっとわかりやすくいうと、1つのコンソールで複数のコンソールを仮想的に展開できるということ。

多くの端末を作成することを可能にすることで、単一画面からアクセスし、制御することができます。 tmuxは、 画面を表示し、バックグラウンドで実行を続けてから、後で再接続できるとのこと。

よく、macのターミナルやitermなどで作業していると、複数のウィンドウを開いて作業していたことがありますが、 接続が切れてしまったり、どのウィンドウがどこのサーバーだったか見にくくて仕方ないときがありました。

これらをまとめて効率的に作業できるようにしてくれるのが、tmuxといったところ。

さっそく導入してみましょう。

導入

$ brew install tmux

インストールしたら、ヴァージョンを確認してみましょう。 ヴァージョンが確認できたら、正常にインストールできていると思います。

$ tmux -V
tmux 2.8

起動

tmuxの起動は、$ tmux で起動できます。 ローカルで実行するとお馴染みのホームディレクトリが展開されるかと思います。

また、終了するには、$ exit です。

起動が確認できると、ウィンドウ下部に以下(ステータスバー)が確認できるかと思います。

f:id:o21o21:20190123141112p:plain

ここまでではただ同じコンソールを展開しただけなので、tmuxの良さが全然わかりませんねw 少し起動してみましょう。

基本コマンド

起動してから、exitしないで(セッションをデタッチ)ぬけてみましょう。

1, 起動: $ tmux

2, 起動してから: Ctr-b + d

[detached (from session 0)]

3, セッション確認: $ tmux ls

そうすると以下のようなセッションが確認できるかと思います。

0: 1 windows (created Wed Jan 23 14:32:44 2019) [204x62]

どうやら、0がセッション名のようです。(もちろんセッション名は任意の名前に変更可能です。)

4, アタッチ: $ tmux a -t 0

これで再接続できたかと思います。

なんとなーくわかってきたでしょうか。 以下に、基本コマンドを書いておきます。 他にもコマンドはあるので、随時気になるコマンドはググってください!

# セッション一覧表示
$ tmux ls

# セッションアタッチ(再接続)
$ tmux a -t <session_name>

# セッション終了
$ tmux kill-session -t <session_name>

# tmux終了
$ tmux kill-server

tmuxチートシート - Qiita

.tmux.conf

ここからがさらに面白いところです。 tmuxというと、カスタマイズ性にとても優れているようです。 カスタマイズには、.tmux.confというファイルを作成し、そこに設定を記述します。

このファイルはホームディレクトリに作成します。(/Users/<user_name>)

$ touch ~/.tmux.conf

このファイルに記述する内容ですが、けっこう個人に左右されるかと思います。

なので、ここでは必要最低限の設定を紹介します。(ウィンドウの分割など)

あとで、この設定を元に、独自の設定が探せるような状態の設定になればと思います!

# Ctr-bのキーバインドを解除
unbind C-b

# prefixキーをC-qに変更
set -g prefix C-q

# window分割("|": 縦, "-": 横)
bind | split-window -h
bind - split-window -v

# re-size panes by vim movements
bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5

# move by vim movements
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R


# ######## SETTINGS status line

# status line を更新する間隔を1秒にする
#set-option -g status-interval 1

# status-right の最大の長さを指定
set-option -g status-right-length 120

set-option -g status-right '#H#(get_load_average_tmux)#{battery_icon}#{battery_percentage}#(get_ssid_tmux)%m/%d %a#[default] %H:%M'
# ######## SETTINGS status line

set -g @tpm_plugins '              \
  tmux-plugins/tpm                 \
  tmux-plugins/tmux-battery        \
'


# Initialize tpm
run-shell ~/.tmux/plugins/tpm/tpm

コメントに書いてある通りの設定になります。

ステータスバーの編集も可能です。自分の使いやすいようにカスタマイズしてみましょう。 バッテリー残量や日付などの設定が可能です。一応上記のファイルでは設定しています。

tpm

上記のファイルでは、tpm(Tmux Plugin Manager)という、tmuxのプラグイン管理ツールを使用しています。 インストールも簡単なので、使用してみるのがいいと思います。

インストールは以下。

$ git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

インストールしたら、.tmux.confプラグインの名前を記述します。

上記ファイルでいうと、set -g @tpm_pluginsの部分ですね。 そして、必ずプラグインを使用するために、run-shell ~/.tmux/plugins/tpm/tpmをファイルの最終行に記述します。

ここまで記述できたら、tmuxを起動し、prefix(上記ファイルでは、Ctr-q) + I でインストールします。

次のtmux起動で適用されます。 また、プラグインのアップデートは、prefix + Uで、 prefix + alt + uで、記述のないプラグインをアンイストールします。

Tips

  • コンソール起動時に、自動でtmuxを起動(.bash_profileに記述)
if [ $SHLVL = 1 ]; then
  tmux
fi

参考

tmuxで快適なターミナル生活を送ろう - Qiita

tmux の status line の設定方法 - Qiita

【Linux】Linuxの各ディレクトリについて軽くまとめてみた

今回はLinuxのおけるディレクトリについてまとめてみました。

CUIで操作していると、「あれ?このディレクトリってなんのためにあるんけ?」 ってよくその度にググるので、基本情報をまとめました。

Linux

LinuxとはOSの1つであり、Unix系オペレーションシステムカーネルである、 Linuxカーネル、およびカーネルとして周辺を整備したシステムのことである。 厳密にはカーネルのみを指すが、ソフトウェアを組み合わせて1つのソフトウェアパッケージとして提供される。 これを、ディストリビューションと言う。

Linux ディストリビューション

主に、RedHat系とDebian系に大きく2種類に分けられる。

種類については、以下を参照。

Linuxディストリビューション - Wikipedia

よく目にするRHELとは、RedHat系とDebian系に大きく2種類に分けられるEnterpriseLinuxのことで、RedHatの要の製品である。

基礎

Linuxでは、一般的に複数のユーザーが同時に接続できるように構築されているマルチユーザーのOSである。 主に管理者/一般/システムユーザーの3種類である。

管理者はroot(またはスーパーユーザー)で、一般ユーザーはシステムを利用するアカウント、システムユーザーはログイン利用はせず、特定のプログラムを実行するためなどのアカウントになる。

ディレクト

Unix系のOSでは、Filesystem Hierarchy Standard(FHS)といって、ファイルの階層標準が定められている。 だからといって、すべてのLinuxが同じ階層というわけではない。が、ディレクトリの構造が似ている。

/

ルートディレクトリ。 すべてのファイルとディレクトリは / の下に格納される。

/bin

binaries 一般ユーザー向けの基本コマンド群。 (ls, echo, mkdirなどの)どのユーザーでも実行できるコマンド。

Filesystem Hierarchy Standard - 3.4 /bin : Essential user command binaries (for use by all users)

また、基本的にこのディレクトリに新しいコマンドを追加することは推奨されていない。

/usr

User Services and Routines 全ユーザーが使用するアプリのソフトウェアやライブラリ群。

/usr/bin

一般ユーザー向けのの基本でないコマンド群。 言い換えると、/binほど当たり前でないけど日ごろよく使うコマンドを配置する。 AmazonLinux1では、diff, aws, ssh, yumなどが配置されていた。

/usr/lib

/usr/binや/usr/sbinにある基本コマンドの実行に必要なライブラリ群。

/usr/local

ローカルシステムで必要とされるコマンドやライブラリ、ドキュメントなど配置されている。

/usr/local/bin

パッケージ管理ツール以外でインストールした単一ファイルのアプリの格納先に適している。

/usr/local/src

手動でビルドするコードの格納先に適している。

/usr/src

ソースコード群(カーネルソースコードとそのヘッダーファイル群など。)

/usr/share

OSなどに依存しない共有ファイル群。 各アプリで使用されるデータベースや、manコマンドで使用されるマニュアルが格納されている。

/sbin

system bainaries rootユーザー向けのシステム管理コマンド群。 主に、起動/停止/リカバリーなどのシステム管理に必要なコマンドが配置されている。 一般ユーザーでは実行できないように権限が設定されているコマンドもある。

/etc

エトセ(et cetera) 設定ファイル群。システムやアプリに関わる設定ファイルなど。

/lib

システムの起動時に必要なものと、/bin, /sbinにある基本コマンド実行に必要なライブラリ

/lib64

64bitの場合、使用されるライブラリが格納されているディレクトリ。

/opt

option パッケージ管理ツール以外でインストールしたディレクトリ構造になっているアプリ(コード)の格納先。

/etc/opt

optの設定ファイル

/sys

system ドライバ関連のプロセス情報群。

/boot

boot loader システムの起動に必要なファイル群。 普段このディレクトリにあるファイルを変更することは滅多にない。

/dev

device 基本デバイスファイル群。(デバイスもファイルとして扱う) デバイスファイルを、Open,Read,Write,Closeという順にアクセスするようになっている。

/var

variable 一時ファイルを保存しておくディレクトリ。(可変ファイル群) ただし、このディレクトリに格納されているファイルは、サーバーの再起動で削除されない。 ログなど

/mnt

mount リムーバブルメディアを使用するときに利用されるマウントポイント用ディレクトリ。

/media

リムーバブル媒体(DVD-ROMなど)のマウントポイント。

/tmp

temporary files 一時ファイル群。サーバーの再起動で削除される。

/home

各ユーザーのホームディレクトリがあるディレクトリ。

Linuxによって、若干の違いや見たことないディレクトリはもちろん存在します。 また、ヴァージョンアップされたときなど、変更点をチェックするようにしないといけません。 構成管理ツールなどを使用して、自動化をしている場合、ディレクトリの変更や、 システムの起動方法に変更がかかっているとなると、大幅に改修が必要かもしれません。

AmazonLinuxもAL2を使用することができますが、いくつか変更点がやっぱりあります。

Amazon Linux と Amazon Linux 2 の技術面の違い - Qiita

ですが、基礎のディレクトリを把握しておくことで、臨機応変に考えることができそうです。

以上.

【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-8listen 80の設定は2つのlocationブロックにも適用される。 つまり、あるlocationに対して、独自の設定を宣言したい場合は、locationブロック内で宣言する。

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

C10K問題

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

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

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

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

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

【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実行する際に必要なものです。

JDKJREは同梱されていますが、別物として理解しておくといいかもしれません。 ここでは細かい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で変更が確認できるかと思います。

以上.

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

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

(随時更新中~~~~~~~~~~~~~~~)

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

ホワイトペーパー | AWS

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

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

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

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

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

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

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

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

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

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

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

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

  • Iaas

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

  • PaaS

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

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

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

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

  • ハイブリッド

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

  • オンプレミス

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

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

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では、クラウドのセキュリティを管理する一方、クラウド内のセキュリティについてはmお客様ので責任である。 つまり、所有するコンテンツ、プラットフォーム、アプリケーション、システム、ネットワークを保護するために 実装するセキュリティの管理権限を保持しているということになる。 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に統合されているため、開発から本番までのワークフローwp簡略化できる。 このサービスには、前払い料金や長期契約はない。リポジトリに保存したデータ量とインターネットに送信されたデータ量に対してのみ料金が発生。

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

以下、メリット。

  • 高性能

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

  • 高い安全性

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

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

  • 高スケーラブル

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

  • 高可用性と耐久性

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

  • 完全マネージド型

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

RDS

クラウド内のリレーショナルデータベースのセットアップ、運用、スケールが簡単である。 Aurora、PostgreSQLMySQLMariaDBOracle、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のインメモリデータまでのスケーラビリティが実現されている。

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

移行

Database Migration Service

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

Server Migration Service

https://aws.amazon.com/jp/server-migration-service/

Snowball

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

Snowball Edge

https://aws.amazon.com/jp/snowball-edge/

Snowmobile

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

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

VPC

AWSクラウドの論理的に分離されたセクションをプロビジョニングし、定義した仮想ネットワーク内のAWSリソースを起動する。 独自のIPアドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定などをコントロールする。 IPv4IPv6の両方を使用できる。 ネットワークの設定が容易にできる。各サブネットの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

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

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サービスおよびリソースへnアクセスを完全にコントロールすることができる。 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

ウェブアプリなど、ユーザーのサインアップやサインインを簡単に追加する。 FacebookTwitterなどのソーシャル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/

以上.

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

こんにちは。

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

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

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

FIREとは??

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

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

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

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

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を実現しようとすると、どういう計算になるでしょう。

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

例: 年収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という動きも日本国内では、また違ったかたちで実現できるかもしれませんね。

以上.