おいおいおい。AWSをはじめて、そろそろ初心者を名乗っても良いかなと思い始めた今も、俺は結局AWSのCLIでしか作業していないじゃないか、ミドルウェアというものはどこに行ってしまったんだ。
コマンドラインでデータベースを起動したら、それが自動でレプリケーションされるわ、バックアップは取られているわでかなり便利になっているのはわかった。でも、なんか物足りなさを感じている。今日はもうクラウドの醍醐味を味わうために、AutoScalingというのに挑戦してみることにする。
AMI
とりあえず、俺はWebアプリケーションを動かす事をしてみたいから何か適当に構築しながらAutoScalingを楽しんで行ってみたいと思う。最終回にしてやっとEC2にログインしてpingとexit以外のコマンドを打つ時が来た。AuctoScalingというのを使うためにはまずはAMIというのを作る必要があるらしい。まずは既存のイメージからEC2を起動し、簡単なWEBアプリケーションを作り、そこからAMIを作成するということをする。
AMIを作るときのVPCは特にどこでも良いらしい。ただ、Security Groupのことなどを考えると、動かしたい所でAMIを作ったほうが、あとあとの手間が減りそうなのは想像がつくから、稼働させたいVPCで作ることにする。
ちょっとこのあたりで、先週までに作っていた構成 を確認も兼ねてまとめてみることにする。
$ aws ec2 describe-vpcs
$ aws ec2 describe-subnets
$ aws ec2 describe-internet-gateways
$ aws ec2 describe-route-tables
これでネットワークのCIDRとそれぞれのIDを列挙しておくことができた。
これがあったほうがこの後の作業が楽だということにはこの数日間で思い知らされている。もし、CLIだけでやるときは、できることなら、この図のようにidとCIDRのセットをまとめておくことをおすすめする。
$ aws ec2 describe-key-pairs
key-pairの名前もこれで[id_rsa]だということがわかった。
$ aws ec2 describe-security-groups
今回はSecurity Groupについてはもう一度作り直していくことにした。
$ aws ec2 create-security-group --vpc-id vpc-6ac1020f --group-name webapp-ssh --description "eccube-web server ssh SG"
{
"GroupId": "sg-d2e353b7"
}
Security Groupを作ったら、sshが接続できるようにする。
$ aws ec2 authorize-security-group-ingress --group-id sg-d2e353b7 --port 22 --protocol tcp --cidr m.y.I.p/32
Security Group管理表
ID
Name
Source
Protocol
sg-d2e353b7
webapp-ssh
myIp
TCP:22
改めてEC2を起動しようと思ったけど、AMIのIDを覚えていないので、もう一度AMIのIDを調べるところからやり直す。これは、今後も頻繁に発生しそうだから、何かしらScriptを作っておくといいんだろう。
$ aws ec2 describe-images --owners amazon |jq '.[][] |select(.ImageType == "machine") | {"Name" :.Name,"ImageId":.ImageId }' |grep -A 1 amzn-ami-hvm
このコマンドで、一番新しそうなamiを探して、起動時の--image-idに指定する
$ aws ec2 run-instances --key-name id_rsa --instance-type t2.micro --subnet-id subnet-d806ee81 --associate-public-ip-address --security-group-ids sg-d2e353b7 --image-id ami-35072834
これでEC2が立ち上がった。
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
無事にログインもできたし、ここからはついにping以外のコマンドを投入していく時間だ。
$ sudo yum install httpd mysql php php-mbstring php-pdo php-mysql php-mcrypt
$ sudo chkconfig httpd on
なんだろう。いつもなら何も感じないこんなコマンドも、クラウド上でやるとこんなに感動的なのか。
とりあえず、今起動したApacheの動作を見るために、Security GroupでHTTPを開ける。
$ aws ec2 create-security-group --vpc-id vpc-6ac1020f --group-name webapp-http --description "eccube-web server http SG"
{
"GroupId": "sg-b15eeed4"
}
$ aws ec2 authorize-security-group-ingress --group-id sg-b15eeed4 --port 80 --protocol tcp --cidr 0.0.0.0/0
これで、Security Groupはこうなっている。
ID
Name
Source
Protocol
sg-d2e353b7
webapp-ssh
myIp
TCP:22
sg-b15eeed4
webapp-http
0.0.0.0/0
TCP:80
今作ったhttpへのアクセスを認めていたSecurity Group webapp-httpを起動しているインスタンスにくっつけてみる。さっきEC2を起動した時にpublic IPばかり気にしてしまっていて、instance-idを残しておくのを忘れてしまっていた。
describe-instancesでインスタンスの情報を取得するというのも有りだけど、今回は別の方法でinstance-idを調べてみる。インスタンスにsshで接続できている事が前提になるけど、ec2-metadataというコマンドがあって、そのec2のいろいろな情報が見られる。
$ ec2-metadata
ami-id: ami-35072834
ami-launch-index: 0
ami-manifest-path: (unknown)
ancestor-ami-ids: not available
block-device-mapping:
ami: /dev/xvda
root: /dev/xvda
instance-id: i-44eb0fb1
instance-type: t2.micro
local-hostname: ip-172-16-32-209.ap-northeast-1.compute.internal
local-ipv4: 172.16.32.209
kernel-id: not available
placement: ap-northeast-1c
product-codes: not available
public-hostname:
public-ipv4: 54.x5.1xx.176
public-keys:
keyname:id_rsa
index:0
format:openssh-key
key:(begins from next line)
ssh-rsa =*********************************************************************************************************************==_id_rsa
ramdisk-id: not available
reservation-id: r-033810f1
security-groups: webapp-ssh
user-data: not available
けっこう便利かもしれない。これでinstance-idがわかったので、改めてSecurity Groupを付けなおす。Security Groupをつけるときは、modify-instance-attribute だろう多分。
$ aws ec2 modify-instance-attribute --groups sg-d2e353b7 sg-b15eeed4 --instance-id i-44eb0fb1
そしてApacheを起動して
$ sudo service httpd start
ブラウザでアクセスしてみる。
“Amazon Linux AMI Test Page” と無事に表示された。感無量。
このままテストページで何かしても面白くないので、何かデータベースとつなぐものを動かしたい。そのためにもまずはSecurity Groupの設定を、今作ったmysql用のSecurity GroupをEC2とRDSにそれぞれ割り当てる。
$ aws ec2 create-security-group --group-name webapp-mysql --vpc-id vpc-6ac1020f --description mysql
{
"GroupId": "sg-b4ac1fd1"
}
$ aws ec2 authorize-security-group-ingress --group-id sg-b4ac1fd1 --source-group sg-b4ac1fd1 --port 3306 --protocol tcp
ID
Name
Source
Protocol
sg-d2e353b7
webapp-ssh
myIp
TCP:22
sg-b15eeed4
webapp-http
0.0.0.0/0
TCP:80
sg-b4ac1fd1
webapp-mysql
sg-b4ac1fd1
TCP:3306
$ aws ec2 modify-instance-attribute --groups sg-d2e353b7 sg-b15eeed4 sg-b4ac1fd1 --instance-id i-44eb0fb1
$ aws rds modify-db-instance --vpc-security-group-ids sg-b4ac1fd1 --db-instance-identifier test-db
Security Groupを変更してみて、EC2からデータベースにアクセスできるのかどうかを確かめてみる。
$ mysql -h test-db.**********.ap-northeast-1.rds.amazonaws.com -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.6.19-log MySQL Community Server (GPL)
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
mysqlに接続できること。なんだろう、当たり前のことなんだけど、環境がクラウドになるだけでこんなにも嬉しいものなのかという感動をかみしめている。
簡単なWebアプリケーション
ミドルウェアとかその辺はこれで良いと思うけれど、今度はWebアプリケーションを作って動かしてみたいと思う。その前に、PHPでTimeZoneを設定しておく。
$ diff -Nur /etc/php.ini /etc/php.ini.orig
--- /etc/php.ini 2015-02-21 09:09:04.988734049 +0000
+++ /etc/php.ini.orig 2015-02-21 09:05:49.630312476 +0000
@@ -953,7 +953,7 @@
[Date]
; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
-date.timezone = Asia/Tokyo
+;date.timezone =
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.default-latitude
;date.default_latitude = 31.7667
そして、index.phpを作る。
<html>
<head>
<title>test application</title>
</head>
<body>
<h1>InstanceID = <?php
$instance_id = file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');
echo $instance_id;
?></h1>
あなたは
<?php
$dsn = 'mysql:dbname=counter;host=test-db.cojvgercnfvt.ap-northeast-1.rds.amazonaws.com';
$user = 'USERNAME’;
$password = *************;
try{
$dbh = new PDO($dsn, $user, $password);
$sql = "SELECT counter FROM counter LIMIT 1";
$stmt = $dbh->query($sql);
$result = $stmt->fetch(PDO::FETCH_ASSOC);
echo $result['counter'];
$sql = 'update counter set counter = counter + 1; ';
$stmt = $dbh->prepare($sql);
$flag = $stmt->execute(array());
$dbh = null;
}catch (PDOException $e){
print('Connection failed:'.$e->getMessage());
die();
}
?>人目の訪問者です。
</body>
</html>
すごくシンプルに、インスタンスIDとアクセスカウンターを表示するだけのアプリケーションをGoogleとコピペを駆使して頑張って開発した。
このアプリケーションをAutoScalingでスケーリングさせてみる。そのためにはまず、このアプリケーションの入ったインスタンスからAMIを作らなくちゃいけない。
$ aws ec2 create-image --instance-id i-44eb0fb1 --name access-counter-version-1
{
"ImageId": "ami-e118fbe1"
}
できているかの確認をするために、describe-images というコマンドを --owners をselfにして実行しみる。
$ aws ec2 describe-images --owners self
{
"Images": [
{
~略~
"ImageId": "ami-e118fbe1",
"State": "pending",
}
~略~
]
}
State:の所がpendingからavailableになればAMIの作成は完了だ。
ELB
AMIを作る所までできたら、ロードバランサーを作ってみる。
$ aws elb create-load-balancer --load-balancer-name webapp-lb --subnets subnet-d806ee81 subnet-e300d794
usage: aws [options] <command> <subcommand> [parameters]
aws: error: argument --listeners is required
なんとなくオプションを指定して実行してみるけれど、listenersというのが必要らしい。しかし、listenersに指定するものが何かよくわからない。困ったときのhelpということで、
$ aws elb create-load-balancer help
~略~
[
{
"Protocol": "string",
"LoadBalancerPort": integer,
"InstanceProtocol": "string",
"InstancePort": integer,
"SSLCertificateId": "string"
}
...
]
~略~
listenerにはJSON形式か、ズラーっとパラメータを並べる方法があるらしい。
とりあえず、今回はJSON形式で入れてみることにする。
$ aws elb create-load-balancer --load-balancer-name webapp-elb --subnets subnet-d806ee81 subnet-e300d794 --listeners '[{"Protocol":"tcp","LoadBalancerPort":80,"InstanceProtocol":"tcp","InstancePort":80}]'
{
"DNSName": "webapp-elb-1316290153.ap-northeast-1.elb.amazonaws.com"
}
無事にELBが作成できたっぽいけれど…、
$ curl webapp-elb-1316290153.ap-northeast-1.elb.amazonaws.com
反応がない。
だがしかし、ここまで何度も反応が無いことは経験している。たいていの場合Security Groupだった。今回も同じようにELBに対してSecurity Groupを設定する。
$ aws elb apply-security-groups-to-load-balancer --load-balancer-name webapp-elb --security-groups sg-b15eeed4
{
"Security Groups": [
"sg-b15eeed4"
]
}
$ curl webapp-elb-1316290153.ap-northeast-1.elb.amazonaws.com
curl: (52) Empty reply from server
無事に空っぽのレスポンスが返ってくるようになった。
今はおそらくこんな感じで、AMIを作るために立ち上げたEC2がひとつと、二つのサブネットにまたがった、ELBがひとつある状態になっているんだろう。このELBに対して、EC2をつなげてあげれば、elbはきちんとしたレスポンスを返してくるはずだ。
aws elb register-instances-with-load-balancer --load-balancer-name webapp-elb --instances i-44eb0fb1
{
"Instances": [
{
"InstanceId": "i-44eb0fb1"
}
]
}
もう一度curlで見てみる。
$ curl webapp-elb-1316290153.ap-northeast-1.elb.amazonaws.com
<html>
<head>
<title>test application</title>
</head>
<body>
<h1>InstanceID = i-44eb0fb1</h1>
あなたは
21人目の訪問者です。
</body>
</html>
おお、きちんと表示されている。素晴らしい。
これで、今の状態はこのような感じになっているはずだ。
AutoScaling
次はついにAutoScalingというのをやってみる。負荷に応じて勝手にサーバができたり、消されたりとクラウドらしい使い方ができるようになるんだ。
AutoScalingと一言で言ってしまっていたけど、AutoScalingでサーバを増減させるためにはいくつかの要素が必要になるらしい。まずはその辺を整理してから手を動かしていきたいと思う。
上の図のようなイメージになっているんだと思うけど、まずはLaunch Configurationを作らなくてはいけなさそうだ。
Launch Configuration
Launch Configurationをまずは作ってみる。
$ aws autoscaling create-launch-configuration --image-id "ami-e118fbe1" --key-name id_rsa --instance-type t2.micro --launch-configuration-name webapp-lc --security-groups sg-b4ac1fd1 sg-b15eeed4
AMIさえ先に作ってあれば、Launch Configurationを作ることは、特に悩むことはなかった。
Security Groupの指定を忘れてしまっていて、後で困ったのは内緒。
Auto Scaling Group
次にAutoScaling Groupを作成する。Auto Scaling Groupにはさっき作ったLaunch Configurationを指定するほかに、subnetIdや最小数(min-size)と最大数(max-size) 、今必要な数(desired-capacity)を指定する。
$ aws autoscaling create-auto-scaling-group --load-balancer-names webapp-elb --launch-configuration-name webapp-lc --vpc-zone-identifier subnet-d806ee81,subnet-e300d794 --min-size 1 --max-size 2 --desired-capacity 2 --auto-scaling-group-name webapp-asg
--vpc-zone-identifierがなんだかわからなかったけど、subnetIdをカンマ区切りで指定するらしい。今回はpublicなsubnetに起動したいので、このような指定をした。もしやと思って、describe-instancesしてみたら、なんとすでに起動し始めていた。試しに、Auto Scaling Groupに今まで起動していたインスタンスも追加してみる。
$ aws autoscaling attach-instances --auto-scaling-group-name webapp-asg --instance-ids i-44eb0fb1
その後に、ちゃんと台数が確保され続けることを確認したい。
$ aws ec2 terminate-instances --instance-ids i-44eb0fb1 i-efc0211a
とりあえず、今はテスト段階なので、全部落としてみる。予想の通りであれば、しばらく経つと全く新しい2台が立ち上がってくるはずだ。
ちょっとここで、一息入れよう。コーヒーを入れて戻って来る5分くらいの間で、どうなっているのか。現在のAuto Scaling Groupに属しているインスタンスを確認してみることにする。
$ aws autoscaling describe-auto-scaling-instances
{
"AutoScalingInstances": [
{
"AvailabilityZone": "ap-northeast-1a",
"InstanceId": "i-3235dd2a",
"AutoScalingGroupName": "webapp-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService",
"LaunchConfigurationName": "webapp-lc-2"
},
{
"AvailabilityZone": "ap-northeast-1c",
"InstanceId": "i-78fe1f8d",
"AutoScalingGroupName": "webapp-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService",
"LaunchConfigurationName": "webapp-lc-2"
}
]
}
なんと、しっかり今まで立ち上がっていたものとは全く別のインスタンスが2台立ち上がっているじゃないか。ここまで予想通りだと、多少驚く。もう少し躓くと思ったのだけど、こんなに何事もなく動くのか、これをオンプレでやれって言われたらとかんがえると…。ブラウザでも一応確認してみる。
2つのタブを開いて、何回もリロードをしてみたら、きちんとアクセスした時に分散されている事が確認できた。ちゃんとアクセスカウンターがいい感じに動いていることも確認できたし、アクセスした時によって、別のインスタンスが返していることも分かった。コレで無事にAutoScalingの構築は完了か?
Scaling Policy
いや、まだだ。このままでは、まだ、サーバが落ちてしまった時に自動的に補充はしてくれるけど、負荷に応じてサーバが増減するみたいなかっこいいことはできてない。このサーバが自動的に増減するというのを実現するために、Scaling Policyというのを作って、Cloud Watchという監視系のサービスから上がってくるアラートでの設定をする必要がある。
順序としては、まずはScaling Policyを作るんだと思う。
$ aws autoscaling create-scaling-po[TAB]
出てこない。
Scaling Policyは作るものじゃないのか?? 知ったかぶって、いきなりcreate-scaling-とか打ってはいけないやつか。久しぶりに思ったとおりに行かない。振り返れば、最初AWSを触り始めた頃 は、思い通りとかそういったことも無かったのに、それと比べるとだいぶコツを掴んできているんだなとも思える。
$ aws autoscaling [TAB]
put-scaling-policyが怪しい。
なんかロードバランサーとか、AutoScalingとか調子に乗っていた気がするので、もう一度初心に帰って、きちんと調べることにする。
$ aws autoscaling put-scaling-policy help
SYNOPSIS
put-scaling-policy
--auto-scaling-group-name <value>
--policy-name <value>
--scaling-adjustment <value>
--adjustment-type <value>
[--cooldown <value>]
[--min-adjustment-step <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton]
必須なのは、auto-scaling-group-name,policy-name,scaling-adjustmentとadjunstment-typeの4つだ。前の2つは名前だからわかるけど、adjustmentの付いている2つ、どちらかは調整する台数の話で合っているとは思うけど、もう1つはなんだろう。とは言え、ちゃんとヘルプには書いてある。
--scaling-adjustmentにはintegerがパラメータとして取られる。--adjustment-typeには ChangeInCapac-ity ExactCapacity PercentChangeInCapacity この3つが指定できるらしい。
それぞれ調べてみると、
ChangeInCapacityはscaling-adjustmentで指定された数だけ増減する
ExactCapacityはScaling-adjustmentで指定された数にする
ParcentChangeInCapacityはScaling-adjustmentで指定したパーセンテージ分増減する
といったものになるみたいだ。このTypeを使いこなすことによって、いろいろなスケーリングが楽しめそうな予感がする。
$ aws autoscaling put-scaling-policy --adjustment-type "ChangeInCapacity" --scaling-adjustment 1 --policy-name scaleout --auto-scaling-group-name webapp-asg
{
"PolicyARN": "arn:aws:autoscaling:ap-northeast-1:376471586427:scalingPolicy:bfb61d87-1314-4425-9ecb-af95a9b952fd:autoScalingGroupName/webapp-asg:policyName/scaleout"
}
$ aws autoscaling put-scaling-policy --adjustment-type "ChangeInCapacity" --scaling-adjustment -1 --policy-name scalein --auto-scaling-group-name webapp-asg
{
"PolicyARN": "arn:aws:autoscaling:ap-northeast-1:376471586427:scalingPolicy:63b8e777-88a2-4509-93ca-b0ced8852ef8:autoScalingGroupName/webapp-asg:policyName/scalein"
}
スケールアウト(サーバ台数を増やす)するときには正の整数を、スケールインするためには負の整数を--scaling-adjustmentに指定してあげれば良いようだ。
PolicyARNという今までに見たことのないような形のレスポンスが来ているが、大丈夫だろうか。ともあれ、これでAuto Scalingの準備は整った。
CloudWatch
あとはCloudWatchという監視のサービスを使って負荷に応じて自動的にスケールイン/アウトするように設定してあげれば良い。
Cloud Watchでは、どうもMetricsというもので、いろいろな値を保持しているらしい。
まずはどんなMetricsがあるのか確かめるため、それっぽいコマンドを探してみる。
$ aws cloudwatch [TAB]
なんとなくそれっぽいのが、何個か見つかった。まずひとつめの
$ aws cloudwatch list-metrics
ヘルプを見たりしながら、これでどのようなmetricsがあるのかを確かめてみる。
$ aws cloudwatch list-metrics --namespace AWS/ELB --metric-name Latency --dimensions '[{"Name":"LoadBalancerName","Value":"webapp-elb"}]'
{
"Metrics": [
{
"Namespace": "AWS/ELB",
"Dimensions": [
{
"Name": "LoadBalancerName",
"Value": "webapp-elb"
}
],
"MetricName": "Latency"
},
~略~
"MetricName": "Latency"
}
]
}
今回はAZにかかわらず、LoadBalancerのLatencyを基準にしたいと思うけれど、そもそも現在どの程度のLatencyがあるのか、見てみないことには始まらない。get-metric-statisticsというコマンドがあったから、実行してみると、大体1e^-5秒くらいのLatencyだということがわかった。
$ aws cloudwatch get-metric-statistics --namespace "AWS/ELB" --metric-name Latency --start-time "2015/02/20T10:00:00Z" --end-time "2015/02/20T14:00:00Z" --period 300 --statistics Average
{
"Datapoints": [
{
"Timestamp": "2015-02-22T11:15:00Z",
"Average": 1.1285146077473956e-05,
"Unit": "Seconds"
},
{
"Timestamp": "2015-02-22T12:50:00Z",
"Average": 1.025199890136719e-05,
"Unit": "Seconds"
},
{
"Timestamp": "2015-02-22T10:00:00Z",
"Average": 9.775161743164062e-06,
"Unit": "Seconds"
},
~略~
],
"Label": "Latency"
}
であれば、多めに見て1秒くらいのLatencyになった時にScalingするように設定してみたいと思う。
$ aws cloudwatch put-metric-alarm --namespace "AWS/ELB" \
--metric-name Latency --period 300 --statistic Average --threshold 1\
--alarm-actions "arn:aws:autoscaling:ap-northeast-1:376471586427:scalingPolicy:bfb61d87-1314-4425-9ecb-af95a9b952fd:autoScalingGroupName/webapp-asg:policyName/scaleout"\
--evaluation-periods 1 --alarm-name webapp-alarm-scaleout\
--comparison-operator GreaterThanThreshold \
--dimensions Name=LoadBalancerName,Value=webapp-elb --unit Seconds
これでELBからのLatencyの5分平均が1秒以上になった時にスケールアウトするはずだ。
Alarm-actionsにはさっき作ったScaling Policyのarnというのを指定するというのがなかなか難しい。というかarnってなんだ。とは言え、親切にhelpに書いてあって助かった。同様にスケールインするときの設定もしてあげる。
$ aws cloudwatch put-metric-alarm --namespace "AWS/ELB" \
--metric-name Latency --period 300 --statistic Average \ --threshold 0.3 \
--alarm-actions "arn:aws:autoscaling:ap-northeast-1:376471586427:scalingPolicy:63b8e777-88a2-4509-93ca-b0ced8852ef8:autoScalingGroupName/webapp-asg:policyName/scalein" \
--evaluation-periods 2 --alarm-name webapp-alarm-scalein\
--comparison-operator LessThanThreshold\
--dimensions Name=LoadBalancerName,Value=webapp-elb --unit Seconds
Latencyの5分平均が0.3を2回連続で下回った場合に台数を減らす設定ができた。
これでAutoScalingGroupで指定した最大の台数と最小の台数の間で、Latencyに応じて自動的に台数が変わるようになった。なんだか、やっとクラウドっぽい事ができたなと思う。
さいごに
なんとかクラウドっぽくサーバが自動的に増減するような仕組みを作るところまでやることができた。
今まで数年間オンプレだけで頑張ってきたけど、この数日間の練習はクラウドだから簡単にできるって事があるっていうことを俺が理解するには十分だった。
まだまだ知らないAWSのサービスは何十個もあるけれど、ここまでできるようになれば次の案件ではクラウドを使う事を検討できるんじゃないかと思う。
この数日間、AWSCLIを使って、クラウドらしいことをやろうと思ってやってきたけれど、ほとんどが今までやってきたようなサーバ周りのお仕事がコマンドだけで、済んでしまうというのにものすごく興味を持った。家で椅子に座ったまま、データセンターの構築ができるようなイメージ、嫌いじゃない。こんな面白いものがあるから、後輩たちにも少し触ってみろよと伝えよう。
マウスが嫌いなとあるインフラエンジニア。「 流行っているな」ぐらいに思っていたクラウド・AWSも、遂には実環境での利用を検討するまでに至ったようす。でも「インフラ屋の戦いはこれからだっ!」
以上、全6回の連載はいかがでしたでしょうか。本連載では、旧来型の業務内容やスキルセットから、「 クラウド」というフワフワしたもの(実際に業務で自分が利用することは真剣に考えたことがなかったもの)を習得するに至るまでの様子をリアルな日記(?)で再現しました。さまざまな試行錯誤をしながらスキル習得していくのがエンジニアの生き様、というのはそのとおりですが、パソナテックではそんなエンジニアの姿勢を応援しつつ、効率的にAWSを学びながら働ける環境(Work Program for AWS) を用意しています。よろしければぜひ、インフラ屋のキャリアパスのひとつに、ご参考にしてみてください。
Work Program for AWS
URL:http://www.pasonatech.co.jp/search/pj/acgp.jsp