【AWS】AutoScaleの設定について

最近業務でAWSのAutoScale機能を利用してサービスの運用をしています。
そこで培ったノウハウや設定内容を記載していこうと思います。

まず、AWSで利用できるAutoScaleの設定では主に2通りの方法がある。
・負荷によるサーバの増減
・指定時間によるサーバの増減

どちらの増減方法においても、AutoScalingGroupを作成し、そのグループに対してアクションを設定することになります。

AutoScaleで設定する内容

1: LaunchConfigの設定
- オートスケールで起動させるインスタンスのAMIを指定
2: AutoScalingGroupの設定
- オートスケールさせるサーバグループの設定
3: ScaleOutPolicy or ScaleInPolicyの設定
- スケールアウト or スケールインの設定
4: ScaleOutAlerm or ScaleInAlermの設定
- スケールアウト or スケールインの発動をさせる条件の設定
5: Scheduleの設定
- 時間毎にサーバ台数を変化させる設定

以下が、AWS AutoScaleの設定において簡単にまとめた概要図です。

AWS AutoScale設定内容

では、実際に設定手順を書いていきます。
前提条件として、AWS コマンドラインツールもしくはコマンドラインインタフェースがインストールされているものとします。

1: LaunchConfigの設定

LaunchConfigNameの設定

~概要~
 この後設定するAutoScalingGroupの設定において利用する、LaunchConfigを特定する識別子
~オプション~
 launch-configuration-name
~設定値~
 LaunchConfigNameを文字列で設定
※ 命名について
  Launch Configの内容について現状は上書きが出来ない
 そのため、例えばAMI IDを新しいものにしたい場合やインスタンスタイプの変更、スポットの入札価格を変えたい場合には、新しくLaunch Configを作りなおさなければいけない
  そこで、AMI (例:ami-12345678)の[ami-]を除いた上位4桁1234を Launch Config名の後ろにつけて管理している
  また、インスタンス名やスポットの仕様の有無、入札価格もわかるようにLaunch Config名で識別している
  例:M3_2XLARGE_1234

———————————————-

起動AMI IDの設定

~概要~
 AutoScaleで起動させるAMIの設定
~オプション~
 image-id
~設定値~
 作成したAMIのIDを指定
———————————————-

Key pair nameの設定

~概要~
 ログインする際に使用する鍵の名前(秘密鍵ファイル名ではなくKey pair name)
~オプション~
 key-name
~設定値~
 作成したKey pair nameを指定する

———————————————-

セキュリティーグループの設定

~概要~
 起動インスタンスに設定するセキュリティグループIDを指定する
~オプション~
 security-groups
~設定値~
 作成したセキュリティグループ名を指定する

———————————————-

インスタンスタイプの設定

~概要~
 起動するインスタンスのインスタンスタイプ名を指定する
~オプション~
 instance-type
~設定値~
 インスタンスタイプ名を指定する
 参考:http://aws.amazon.com/jp/ec2/instance-types/#selecting-instance-types

———————————————-

スポットインスタンス利用有無の設定

~概要~
 スポットインスタンスを使用する場合、スポット入札価格を指定する
~オプション~
 spot-price
~設定値~
 例)$3で入札する場合
 –spot-price “3.0″

実行コマンド

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

 [通常インスタンス]

 aws autoscaling create-launch-configuration --launch-configuration-name ${CONFIG_NAME} --image-id ${AMI_ID} --key-name ${KEY_NAME} --security-groups ${SECURITY_GROUP} --instance-type ${INSTANCE_TYPE}

 [スポットインスタンス]

 aws autoscaling create-launch-configuration --launch-configuration-name ${CONFIG_NAME} --image-id ${AMI_ID} --key-name ${KEY_NAME} --security-groups ${SECURITY_GROUP} --instance-type ${INSTANCE_TYPE} --spot-price "${WEB_SPOT_PRICE}" 

AWS コマンドラインツールの場合

 [通常インスタンス]

 as-create-launch-config ${CONFIG_NAME} --image-id ${AMI_ID} --key ${KEY_NAME} --group ${SECURITY_GROUP} --instance-type ${INSTANCE_TYPE}


 [スポットインスタンス]

 as-create-launch-config ${CONFIG_NAME} --image-id ${AMI_ID} --key ${KEY_NAME} --group ${SECURITY_GROUP} --instance-type ${INSTANCE_TYPE} --spot-price "${WEB_SPOT_PRICE}" 

リファレンス

AWS: create-launch-configuration

その他コマンド

設定確認コマンド

CLI(コマンドラインインタフェース) aws autoscaling describe-launch-configurations
CLT(コマンドラインツール) as-describe-launch-configs

設定削除コマンド

CLI(コマンドラインインタフェース) aws autoscaling elete-launch-configuration –launch-configuration-name ${CONFIG_NAME}
CLT(コマンドラインツール) as-delete-launch-config ${CONFIG_NAME}

※ 補足 -f オプションをつけると削除確認を聞かれることなく強制的に削除が出来る。

その他注意事項

削除する際に、Auto Scaling Groupで削除対象のLaunch Configが使われている場合は、削除できない

2: AutoScalingGroupの設定

AutoScalingGroup名

~概要~
 負荷に合わせたサーバの増減やスケジュール機能を利用する際に、Auto Scaling Groupを特定する識別子
~オプション~
 auto-scaling-group-name
~設定値~
 グループ名の設定

———————————————-

LaunchConfig名の設定

~概要~
起動するAMIやインスタンスタイプを指定したLaunchConfig名を指定する
~オプション~
 launch-configuration-name
~設定値~
 LaunchConfigで作成したLaunchConfig名

———————————————-

アベイラビリティゾーンの設定

~概要~
オートスケールによって起動させるインスタンスのアベイラビリティゾーンを指定する
~オプション~
 availability-zones
~設定値~
 A ゾーン : ap-northeast-1a
 C ゾーン : ap-northeast-1c
 均  等 : ap-northeast-1a,ap-northeast-1c
  ※ 東京リージョンの場合

———————————————-

サーバの最小起動台数の設定

~概要~
 最低何台サーバを起動させるかを指定する。0以上の場合、設定したタイミングでサーバが指定台数起動する
~オプション~
 min-size
~設定値~
 最小起動台数の整数値

———————————————-

サーバの最大起動台数の設定

~概要~
 最大何台までサーバを起動させるかを指定する。現在の起動台数が指定台数よりも多い場合、指定した台数までサーバ台数が減少する
~オプション~
 max-size
~設定値~
 最大起動数の整数値

———————————————-

登録するロードバランサの設定(必要があれば)

~概要~
 起動したインスタンスがぶらさがるロードバランサ名を指定する
~オプション~
 load-balancer-names
~設定値~
 Load Balancer Nameを指定する

———————————————-

タグの設定(必要があれば)

~概要~
 起動したインスタンスに設定するタグを指定する
~オプション~
 tags
~設定値~
 ”k=key名, v=値”
 例)
  –tag “k=site, v=${SITE_NAME}” –tag “k=platform, v=${PLATFORM}” –tag=”k=server, v=img”

———————————————-

terminatする順序の設定(必要があれば)

~概要~
 オートスケールによって削除されるサーバの対象を選択するポリシーを指定する
 AWSでは、起動したタイミングで1時間の課金が発生するため、デフォルトでは、次に課金されるまでに一番近いインスタンスから削除される
 例)
  2時間58分起動している Aインスタンス あと2分で次の1時間分の課金が発生する
  3時間40分起動している Bインスタンス あと20分で次の1時間分の課金が発生する
  ⇒ 次に課金が発生するまでに一番近いのはAインスタンスのため先にAインスタンスが削除される
~オプション~
 termination-policies
~設定値~
 調査中

実行コマンド

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


 aws autoscaling create-auto-scaling-group -auto-scaling-group-name ${AUTO_SCALING_GROUP_NAME} --launch-configuration-name ${LAUNCH_CONFIG_NAME} --min-size ${MIN_SIZE} --max-size ${MAX_SIZE} --availability-zones ap-northeast-1a,ap-northeast-1c --load-balancer-names ${ELB_NAME} --tag "k=site, v=${SITE_NAME}" --tag "k=platform, v=${PLATFORM}" --tag="k=server, v=img" 

AWS コマンドラインツールの場合


   as-create-auto-scaling-group ${AUTO_SCALING_GROUP_NAME} --launch-configuration ${LAUNCH_CONFIG_NAME} --availability-zones ap-northeast-1a,ap-northeast-1c --min-size ${MIN_SIZE} --max-size ${MAX_SIZE} --load-balancers ${ELB_NAME} --tag "k=site, v=${SITE_NAME}" --tag "k=platform, v=${PLATFORM}" --tag="k=server, v=img" 

リファレンス

AWS: create-auto-scaling-group

その他コマンド

設定確認コマンド

CLI(コマンドラインインタフェース) aws autoscaling describe-auto-scaling-groups
CLT(コマンドラインツール) as-describe-auto-scaling-groups

設定削除コマンド

CLI(コマンドラインインタフェース) aws autoscaling delete-auto-scaling-group –auto-scaling-group-name ${AUTO_SCALING_GROUP_NAME}
CLT(コマンドラインツール) as-delete-auto-scaling-group ${AUTO_SCALING_GROUP_NAME}

※ 補足 -f オプションをつけると削除確認を聞かれることなく強制的に削除が出来る。

3: ScakeOutPolicy or ScakeInPolicyの設定

オートスケールでスケールアウトもしくはスケールインの設定を行う
スケールインもスケールアウトもこちらの手順で行うことが出来る

スケールポリシー名の設定

~概要~
 設定するスケールポリシー名を指定する
~オプション~
 policy-name
~設定値~
 スケールアウトかスケールインかをこの値で識別出来るようにしておくのが望ましい
 例:
  ~~_OUT_POLICY、~~~_IN_POLICY

———————————————-

スケールポリシーを適用させるAutoScalingGroupの設定

~概要~
 スケールポリシーを適用させるAutoScalingGroup名を指定する
~オプション~
 auto-scaling-group-name
設定値
 AutoScalingGroupで作成した、AutoScalingGroup名を指定する

———————————————-

スケール時に増減させる数のタイプを指定する

~概要~
 増減させるサーバの「台数指定」や「全体の何割の台数を指定」などの変化タイプを指定する
~オプション~
 adjustment-type
~設定値~
 台数指定:ChangeInCapacity
 調査中 :ExactCapacity
 調査中 :PercentChangeInCapacity

———————————————-

adjustment-typeで指定した、スケール時にサーバの変化値を設定する

~概要~
 サーバ台数の変化値を指定する
~オプション~
 scaling-adjustment
~設定値~
 台数の場合は、整数値を指定する

———————————————-

クールダウンの設定

~概要~
 トリガーを発動させてから次のトリガー発動までの時間を設定する
 例えばトリガーを発動してから10分間は何もせず様子見を行うなどの設定が出来る
 トリガー発動後からサービスとして稼働するまでには多少時間がかかるため、サービス稼働時間から数分くらいの間隔を設定しておくほうが良い
~オプション~
 cooldown
~設定値~
 秒数で指定
 例)15分で指定する場合
  –cooldown 900

実行コマンド

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


 aws autoscaling put-scaling-policy --policy-name ${POLICY_NAME} --auto-scaling-group-name ${AUTO_SCALING_GROUP} --adjustment-type ChangeInCapacity --scaling-adjustment 2 --cooldown 900

AWS コマンドラインツールの場合


 as-put-scaling-policy ${POLICY_NAME} --auto-scaling-group ${AUTO_SCALING_GROUP} --adjustment=2 --type ChangeInCapacity --cooldown 900 --region ap-northeast-1

実行結果

 「arn:aws:…」から始まる表示は、次のアラーム設定時に必要となるのでメモしておく

リファレンス

AWS put-scaling-policy

その他コマンド

設定確認コマンド

CLI(コマンドラインインタフェース) aws autoscaling describe-policies
CLT(コマンドラインツール) as-describe-policies

設定削除コマンド

CLI(コマンドラインインタフェース) aws autoscaling delete-policy –policy-name ${POLICY_NAME}
CLT(コマンドラインツール) as-delete-policy ${POLICY_NAME}

※ 補足 -f オプションをつけると削除確認を聞かれることなく強制的に削除が出来る。

4: ScaleOutAlerm or ScaleInAlermの設定

スケールアウト及びスケールインの発動をさせる条件の指定を行う

スケールポリシー名の設定

ScaleAlermの設定
~概要~
~オプション~
~設定値~

———————————————-

CloudWatchで管理するnamespaceの設定

~概要~
 CloudWatchのCustom Metricsで表示するグループ名の指定
~オプション~
 namespace
~設定値~
 例)–namespace “EC2/AutoScalingGroup”

———————————————-

CloudWatchの表示設定

~概要~
 CloudWatchで表示する際のカラム名と値の設定を行う
~オプション~
 dimensions
~設定値~
 例)–dimensions “AutoScalingGroupName=${AUTO_SCALING_GROUP}”

———————————————-

監視する項目の設定

~概要~
 CloudWatchで監視している監視項目(metric)の指定
~オプション~
 metric-name
~設定値~
 EC2のデフォルトだと以下の10項目を使用できる
 - CPUUtilization
 - DiskReadBytes
 - DiskReadOps
 - DiskWriteBytes
 - DiskWriteBytes
 - NetworkIn
 - NetworkOut
 - StatusCheckFailed
 - StatusCheckFailed_Instance
 - StatusCheckFailed_System

 ・CustomMetricsの設定
  デフォルトではロードアベレージを監視できないためCustomMetricsを登録する必要がある。

  CustomMetricsの設定については別記事にて
  参考ページ:CloudWatchのカスタムメトリクス
———————————————-

監視する項目の設定

~概要~
 監視項目の「測定値」の算出方法
 アラートを出す際の測定が複数サーバの合計値や平均値といった指定を行うことが出来る
~オプション~
 statistic
~設定値~

対象台数 SampleCount
平均値 Average
合計値 Sum
最小値 Minimum
最大値 Maximum

———————————————-

CloudWatchによる監視間隔の指定

~概要~
 CloudWatchによる監視間隔を指定する
~オプション~
 period
~設定値~
 秒数で指定する。
 60秒間隔で指定、最低60秒

———————————————-

閾値オーバー時のトリガー発動までの間隔の設定

~概要~
 閾値オーバーが観測された場合のトリガー発動回数を指定する
 計測値の閾値オーバーが何回連続で検知されたらトリガーを発動するという指定を行う
~オプション~
 evaluation-periods
~設定値~
 3回連続で閾値オーバーの時トリガーを発動するという指定の場合
  –evaluation-periods 3

———————————————-

閾値を検知するための測定値との不等号の設定

~概要~
 測定された結果と閾値を比べる際の不等号の設定を行う
~オプション~
 comparison-operator
~設定値~

< = GreaterThanOrEqualToThreshold
< GreaterThanThreshold
> LessThanThreshold
>= LessThanOrEqualToThreshold

 例)
  閾値の指定が測定値が5以上のとき
  –comparison-operator GreaterThanThreshold 閾値の設定

———————————————-

トリガー発動のに対する閾値の設定

~概要~
トリガー発動に対する閾値の設定を行う
単位はmetric-nameで指定した監視項目の値に関連する
~オプション~
threshold
~設定値~
 ロードアベレージが5以上としていするとき
  –threshold 5 –comparison-operator GreaterThanThreshold

———————————————-

トリガー発動時のポリシーの設定

~概要~
 トリガー発動時にどのScalePolicyを適用するかの指定を行う
~オプション~
 alarm-actions
~設定値~
 ScalePolicyで作成した際に出力されたarm:aws…の値を指定する
 –alarm-actions arn:aws:…….

実行コマンド

 条件:1分間隔で計測し、ロードアベレージが3回連続5以上を検知した場合にアラームを発動させる

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


 aws cloudwatch put-metric-alarm --alarm-name ${ALARM_NAME} --namespace  "EC2/AutoScalingGroup" --dimensions "AutoScalingGroupName=${AUTO_SCALING_GROUP}" --metric-name ${METRIC_NAME} --statistic Average --period 60 --evaluation-periods 3 --comparison-operator GreaterThanThreshold --threshold 5 -alarm-actions ${ALARM_ACTIONS}

AWS コマンドラインツールの場合


 mon-put-metric-alarm ${ALARM_NAME} --namespace "EC2/AutoScalingGroup" --dimensions "AutoScalingGroupName=${AUTO_SCALING_GROUP}" --metric-name ${METRIC_NAME} --statistic Average --period 60 --evaluation-periods 3 --comparison-operator GreaterThanThreshold --threshold 5 -alarm-actions ${ALARM_ACTIONS}

リファレンス

AWS put-metric-alarm

Scheduleの設定

時間帯によってサーバ台数を変化させる設定を行う

スケジュール名の設定

~概要~
 スケジュール名を指定する
 何時に実行するかをスケジュール名からわかる命名にしている
~オプション~
 scheduled-action-name
~設定値~
 2時に実行する場合の命名
  0200_ACTION

———————————————-

スケジュールで変化させるAutoScalingGropの設定

~概要~
 スケジュールによって増減させるAutoScalingGropを指定する
~オプション~
 auto-scaling-group-name
~設定値~
 AutoScalingGropで作成したAutoScalingGrop名を指定する

———————————————-

スケジュール実行時間の指定

~概要~
cronと同じ指定で行える
 グリニッジ標準で指定する必要があるため、日本時間より9時間の設定する必要がある
~オプション~
 recurrence
~設定値~
 2時に指定する場合
  –recurrence “0 17 * * *”

———————————————-

サーバ台数の指定

~概要~
 指定時間に起動させておくサーバ台数の指定する
~オプション~
 desired-capacity
~設定値~
 2台にする
  –desired-capacity 2

実行コマンド

 条件:深夜2時に2台までサーバ台数を減らす

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


 aws autoscaling put-scheduled-update-group-action --scheduled-action-name ${ACTION_NAME} --auto-scaling-group-name ${GROUP_NAME}  --recurrence "0 17 * * *" --desired-capacity 2

AWS コマンドラインツールの場合


 as-put-scheduled-update-group-action ${ACTION_NAME} -g ${GROUP_NAME} --recurrence "0 17 * * *" --desired-capacity 2

リファレンス

AWS put-scheduled-update-group-action

その他コマンド

設定確認コマンド

CLI(コマンドラインインタフェース) aws autoscaling describe-scheduled-actions
CLT(コマンドラインツール) as-describe-scheduled-actions

設定削除コマンド

CLI(コマンドラインインタフェース) aws autoscaling delete-scheduled-action –scheduled-action-name ${ACTION_NAME} –auto-scaling-group-name ${GROUP_NAME}
CLT(コマンドラインツール) as-delete-scheduled-action ${ACTION_NAME} –auto-scaling-group ${GROUP_NAME}

※ 補足 -f オプションをつけると削除確認を聞かれることなく強制的に削除が出来る。

その他

スケジュールの登録については、デフォルトでは20個までしか登録できないようだ。。。

まとめ

現在は、基本的にはスケジュール機能を利用したサーバ台数の変化のみをメインで利用しております。
また、Jenkinsでこのへんの設定を簡単に出来るように設定しているため、それは別途記事にて紹介させて頂きます。

AutoScaleを利用して、急激な負荷増加に備え、またスケジュール機能などを利用して負荷に合わせたサービス運用の自動化を行うのはいかがでしょうか。

参考

AmazonAutoScaling機能について

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

【AWS】CloudFront CDNのキャッシュについて

こちらはまったので注意

『CDNは、データが無いよというネガティブキャッシュも保持する』

ようするに、CDNにアクセスしたが画像がなく、次にS3に画像を参照しに行ったがそこでもなかった場合、「画像がないよ」という情報がCDNに記録されしまうということです。

そのため、S3には画像をあとから上げたとしてもCDNのキャッシュ上にはないという情報が残っているため、キャッシュをクリアしなければいけません。

画像の後ろにタイムスタンプをつけておき(sample.png?20130728004000)、画像が切り替わればタイムスタンプを変更するというスタイルのほうが、好きなタイミングで画像の切り替えを行うことが出来ると感じました。

みなさんもネガティブキャッシュにはご注意を!!

【AWS】Route53を使ってS3のドメインを指定する

AWSを使用しているなら分かりやすさを重視するためにS3のエンドポイントにわかりやすいFQDNをつけてAWSのDNSであるRoute53に登録してみたが下記のようなエラーが出た。


  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist</Message>
  <BucketName>*************</BucketName>
  <RequestId>*******</RequestId>
  <HostId>...</HostId>

エンドポイントに直接アクセスすれば、画像は表示されるのにRote53を経由した場合だとBucketがねぇよ!って怒られる。。。

なんでだろと思ってリファレンスを見ていると、どうやらS3のバケット名とキーの命名規則について

『バケットでは英数字が基本ではあるが、DNS(.s3.amazonaws.com)としても使われる』

なんと!
バケット名と指定するFQDNを同じにしなければいけないとは。。。

バケット名とFQSNを同じにするとRoute53経由で見れるようになりました!!

ちゃんと読めばわかるけど、意外にはまりそうなポイントでした。

参考
http://blog.suz-lab.com/2009/09/amazon-s3.html

http://blog.serverworks.co.jp/tech/2012/08/10/best-practices-for-using-amazon-s3/

デーモン起動・終了時実行の環境変数(パス)の違いに注意

最近、サーバの自動構築にあたり、
サーバ起動時のスクリプトをChefと組み合わせて書いているのですが、そこで問題が。。。

rootユーザでシェルスクリプトをがりがり書いて、sh ~~~で実行確認。
その後サーバの起動時にスクリプトが実行するように/etc/init.d以下に起動スクリプトを作成し、
chkconfig onでサーバを再起動してみると

スクリプトが動いていない

環境変数が違う

調べてみると両者実行時に、環境変数が違うために
コマンドやそれらの設定などが読み込まれずエラーとなるとのこと

rootユーザでのshコマンド実行時とデーモン起動終了時のスクリプトの環境変数の違いについては
以下の記事がすごく参考になりました。

デーモンの起動・終了にはserviceコマンドを利用しよう

そのため、起動スクリプトを記載し確認する際には、
service コマンドを利用して実行しながら確認する必要があります。

serviceコマンドで実行すると、デーモン起動・終了時のスクリプト実行時の環境変数と
同じ環境変数で実行してくれるためいちいちサーバを再起動しなくても確認することはできます。

同じrootで実行してるのなら環境変数も同じにしてくれたらいいのに。。。

CentOSにRedmineを入れてみた

個人的にサービスを友人同士で行いたく、そのプロジェクト管理のためにRedmineを導入してみました!

導入にあたり下記のサイトが非常に役に立ったので共有しておきます。

Redmine 2.2をCentOS 6.3にインストールする手順

つまずいたのは、Rubyのインストール

rootユーザでずっと行なっていたが、rubyのインストール確認でなぜかruby -vと打っても動かず,,,
gemコマンドも使えない状態だったが、一般ユーザに戻って実行すると動かすことが出来た。

rootユーザじゃ使えないのかな!?

でもこれでプロジェクト管理がしやすくなった!

設定系は下記参照!
Redmineのトラッカーやチケットの設定をする

行った設定
・ユーザの追加
・初期はadmin/adminでログインできるためそのユーザの削除
・管理->ロールと管理 で一般ユーザの権限付与
・トラッカーの設定
開発
分析
課題
要望
調査
障害
アイディア

・チケットステータス
新規
作業・担当中
レビュー待ち
フィードバック
終了
却下

・列挙項目のチケット優先度



急いで
すぐに

これでひと通り設定は終了!
メールサーバが入っていないのでメール投げれないのが残念,,,

それにしても、Jenkinsにブログサービス、RedmineにMySQLとその他Webサービス!
1つのサーバに乗せすぎな気もするなぁ...(笑)

関西といえばお好み焼き ~ OKONOMIYAKI ~

今回は、技術と全く関係の無く、大学生の頃よく通っていたお好み焼き屋さんのお話です。

大阪の高槻市にある お好み焼きたこ焼き「虎徹」!!


お好み焼き虎徹ロゴ

小さな個人経営のお店ですが、地域の皆様に愛された地域密着のお店です。

お好み焼き虎徹店舗
そんな「虎徹」のお好み焼きがたまらなく美味しいんです!!

虎徹の鉄板お好み焼き

見て下さい!このふわふわ感☆
チェーン店とはまた違い、個人経営だからこそ培われた本場関西のお好み焼き☆

あぁ〜これって完全にステマですね(笑)

けど騙されたと思って一度食べてみて下さい!
ほんとに美味しいお好み焼きです!

また、最近冷凍販売も初められたそうで!

虎徹の冷凍お好み焼き

何度が食べてみましたが、これまた冷凍とは思えないほどのふわっふわ感☆

虎徹の冷凍お好み焼き

注文がクレジット払いではなく、メール対応からの振込処理なので
ちょっとイケてない感じですが、これも個人経営感が出ててある意味信頼出来ます(笑)

関西出身としてこれは、全国の皆様にも是非食べていただきたい!!と思える味です!!
是非皆様も注文してみてはいかがでしょうか?

と、お好み焼きが無性に食べたくなったので記事にも書いてみました!

※お好み焼き虎徹のHPより画像を引用させて頂いております。
URL: http://okonomi-kotetsu.com/


お好み焼き虎徹ロゴ

Gitでコミット前のファイルを元の状態に戻したいとき

Gitを使っていて間違ってファイルを消してしまった時に、そのファイルのみ元の状態に戻すコマンドです。

下記のページが凄く参考になりました。
git でワーキングディレクトリでファイルを変更したけど元に戻したい場合

実際、git statusコマンドを叩いた時に全部表示されていました!!

# On branch dev
# Your branch is ahead of ‘origin/dev’ by 1 commit.
# (use “git push” to publish your local commits)
#
# Changes to be committed:
# (use “git reset HEAD …” to unstage)
#
# Changes not staged for commit:
# (use “git add
…” to update what will be committed)
# (use “git checkout —
…” to discard changes in working directory)

git add or git rm してしまっている場合には、
git reset HEAD ファイル名

まだaddやrmをしていない場合には
git checkout — ファイル名

で元に戻すことができます。

Gitさん優しくそして凄く便利!!

以上、Gitに関するメモでした。

【勉強会】アプリ開発勉強会!渋谷DeNA 2/12(火)

2013年2月12日(火)にDeNA渋谷オフィス(渋谷ヒカリエ)で行われた、「アプリ開発勉強会!/ソーシャルゲームFlash開発の現状/スマホ時代のWeb/個人サービスの作り方 」の勉強会メモです。

http://atnd.org/events/36367

アジェンダ
土濱 健太郎氏 ソーシャルゲーム業界におけるflash開発の現状
原 一成氏 スマートフォン時代のWeb制作術 Vol.2
菊本 久寿氏 ひとりでできるもん。〜個人サービスの作り方〜」

ソーシャルゲーム業界におけるflash開発の現状

株式会社クルーズの土濱 健太郎さんの発表で、ソーシャルゲームでflashをどのように使っているかや使う時の注意点などをお話されました。

デバイスに合わせてFlashを3種類作成

Flashを作成する際には、デバイスに合わせて3種類を作成し、flash非対応デバイスにはHTML5で再生できる形で対応しているそうです。

  • Android2系

    FlashPlayer7 actionscript7.0
  • ガラケー

    メモリなどの制約が多い
  • iOSやAndroidの非flash向け

    google swiffyで変換して再生
  • iOSやAndroidOS4向け

    flashが再生できないのでHTML5に変換

mobageプラットフォームのexgameは非常に便利

※画像の拡大や透過処理でパフォーマンスが落ちていたがiOS6ではさくさく

でもやっぱりJavaScriptやCSS,Canvasアニメーションが良い!!

ガラケーについて

・容量が100KBを超えると再生しない
・メモリが一瞬でも1024KBを超えると再生しない
・グラデーションの数が多いと再生しない
 ※イラストレーターから取り込んでいるのだが,,,
 カラーポイントは4個くらい,,,

スマホでのFlash利用について

・スマホの解像度を理解してあげる
 あらかじめ大きな画像を置くようにしている

・flashなどは予め使い回しが出来るように作成スべき
 差分を考慮する
 良質なアニメーションは良い設計から始まる

発表後の質問

・ベクター画像、ラスタ画像を埋め込むことは出来るのか?
 容量削減のためベクター画像を使っている
 Photoshopなどで作ったラスタデータを使うことはできるが
 メモリなどの消費量が多く、ベクター画像に偏ってしまった

・合成について
  3つのSWFを合成する際、サーバ側でSWFを1つに合成して実行している
 
・新機種が出た際に動かないSWFなどはどう対処するのか?
 最低ラインに合わせる
 最低ラインが動けばだいたい動く
 if ANDROIDだったらが4系から関係なくなって悲しくなった...

スマートフォン時代のWeb制作術 Vol.2

サイバーエージェントの原さんが、Node.jsでWebSocketを用いたリアルタイム通信のデモを通じてフロントエンジニアもサーバ側の知識が必要になってきますよというお話でした。

発表資料:http://www.slideshare.net/herablog

3つの役割

・Designer
 レイアウト
 高度なWebデザイン
 イラストレーションが専門
 インタラクションに関与

・FrontEngineer
 HTML/CSS/JavaScript
 プログラムの知識のモジュール化
 サーバ知識(Node.jsなど)
 コマンドライン操作
 
・ServerEnginner
 プログラム,サーバ知識
 API作成知識
 最適なインフラ構成構築
 JavaScriptなどHTML5関連

今までは、フロントエンジニアはデザイナーとの関係が深かったですが、これからはコマンドラインやサーバ側の知識が必要になってくるため、サーバ側との関係が深くなってくるよという内容でした。

ひとりでできるもん〜個人サービスの作り方〜

モーションビート技術開発部長である菊本さんのお話で、実際にこれから開発したいと思っている開発者に向けてひとりでもサービスが作れますよという自分の体験談を踏まえたお話と、宣伝とかの手伝いとかをやっていますというプロモーション的な内容でした。

今まで作ったサービス

・レンタルCTO スタートアップの方々にワーキングショップを行なっている
 シャチクのミカタ:http://shachikunomikata.com/
 告白の行方:http://auto-iloveyou.com/

儲からないのになぜやっているの?

 SelfBranding ・・・ 個人のブランディングのため

個人でやってはいけないもの

・仕様がでかい
・勉強でやってみる
仕様がでかすぎると途中で挫折してしまうし、勉強のためにやってみようは結局続かなくなってしまうのがオチ

まずは簡単な仕様でやってみることが大切

どうやって宣伝していくか?

・ソーシャル図鑑
・スタートアップ.jp
・つくログ
・Webサービス図鑑
・ツイートサービス
・個人ブログ
・コンテスト
 ※プレゼンまでもっていけると評価があがる
・Fasebook、Twitter
 ⇒ 継続的に全般していく
 企画段階のタイトルやコピーが重要
・Naverまとめ
 WordpressのSEOはすごい!!
 自分の作ったサイトよりWordPressのSEOの方が効果が高いようだ(経験談)
・インフルエンサーのブログ
 池田勇人さん など

・ネットニュース
 ライフハッカー
 ねとらぼ
 R25
 Yahoo!ニュース(2次掲載)
 はちま トレンドニュース マイナビ
 GIZMODO
 livedoorNews
 ※Web系の場合は連絡なしに掲載してくれる!

思いつきを実現できる環境を

500円でなんでもやってくれる

http://coconala.com/

以上とても刺激のある勉強会でした!

【勉強会】第7回Jenkins勉強会 Oracle 青山センター

2013年1月28日(月)にOracle 青山センターで行われた「第7回Jenkins勉強会」に参加してきた時のメモです。

http://connpass.com/event/1690/

今回の勉強会では、組み込み系が中心でC/C++のプロジェクトでJenkinsを利用している方などの発表でした。基本的には組み込み系であってもWeb系であっても裏側の構成は同じであるが組み込み系ならではの作りや注意点などのお話がありました。

最近作っているプラグインの紹介

Jenkinsのうみの親である川口さんの発表で現在開発中のプラグインについてお話されました。

データベースプラグイン

.目標:
 => 全てのデータをXMLで保存するスタイル
 でも,全てをXMLで保存するのは無理がある

 ・起動速度を向上させる
  ファイルサイズが大きくなりがちなデータ
  テストデータの実行時間履歴
  ファイル指紋(トラッキングに)
  コードカバレッジレポート

 Coreの方でDBに保存する
 ・プラグインでもDB
 Audit to Databaseプラグイン
 Jenkowプラグイン(ワークフローなどをJenkinsに入れてしまう)

 標準UI部品を提供
  再利用可能なGUI付きの部品を提供
  DBコネクタプラグインの提供

 テストのデータとかは大きくなっちゃうけどXMLを廃止するのは考えていませんよ!
 DBプラグインのCore部分が出来たので、みなさん使ってくださいよ!

レシピプラグイン

 Jenkinsで使っているプラグインの一部を取り出してそのまま取り出せるような仕組みにしているプラグイン

 背景:
  新しいプラグインを作ったけどどうやって使い方を説明したらいいかわからない!とか1からユーザに設定をさせるのは面倒だ!
 
 「Export Recipe」 ここから公開できる

 インストール ImportRecipe コミュニティーのレシピのカタログからプラグインを選べることが出来インストールできる
  新規プラグインを作るときに、足りていないプラグインの情報なども表示してくれる

 今後プラグインアップデートセンター的なイメージの場を提供して行きたい

遠隔ターミナル・プラグイン

 ターミナルアクセスを追加する
  ローカルでは動いていてもJenkins上では動かないときにJenkinsのせいにする場合がある
そんな時に、Jenkins上のバッチ処理のデバッグや対話的なスクリプト環境で簡単に試せる場を提供する

 「Interactive Terminal」
  ビルドと同じ環境で走っているターミナル
   これはスレーブで走っている

 ブラウザで出来るターミナル環境があるが
ssh にはバーチャルホストがないが、ssh.configに記入することで出来る
sshでジョブ名.localhostで入れる

 Jenkinsは,基本スレーブで動いている
 Jenkinsのリリース番号が500の大台に乗った!!

質問による解凍

☆画像の比較テストは半端な数になる
 ・500MBくらいの成果物が出てくる
 ・でかすぎてJenkinsのバックアップが取らなくなってきてる
   外部のサーバに閉まってリダイレクト出来るようにして欲しいとかの要望はある
 ・クーロンの代わりにJenkinsを使う機会が多い
  アイノードを食いつくっている 1分に1ジョブ回している

『組み込み業界よくあるJenkins環境構築例』

TechMatrixの天久さんによるお話で、品質に関わる製品を販売されていることからお客様方でのJenkins構築例などを紹介や自社内での導入事例といった内容でした。

静的テスト

・xUnitフレームワークを使ったテスト
 ツールのベンダー
  テストツールの実行環境にJenkinsをおすすめしている
  Jenkinsとテストツールを組み合わせた環境を構築したりしている
  既存の環境に導入することもある

組み込み業界でのJenkins

 みんなどうやっているのか知りたいという人が多い
 エンタープライズ系の話が多く組み込み系がないのがないという声が多い

 組み込みであっても一般的な環境がほとんど...
  利用プラグイン:Cpptest Plugin Jtest

 マスターが1つから
  スレーブでビルドを複数
  スレーブでテストをづく数(静的テストや単体テスト)

 ・どこが組み込みっぽいの?
  ※ビルドがクロスコンパイル
  違う環境でコンパイルを通すことで多様な環境に対応

  

静的テストだけではなく単体テスト

 開発者の人がテストを作ってやっているわけだが...
 ・シミュレーターで実施
 ・単体テストをホスト環境で行う(実際の開発環境でする)
  ⇒シミュレーターがない場合や実機で実施する場合には手間が掛かり過ぎる場合などにホスト環境で実施

 ブランチのマージやモジュールの作成は手動で行なっている

 クラウド上に環境開発を置くのが主流になっているが...
  組み込みのお客さんはコードを外に出すのはためらいがある
  AmazonEC2などに置く事例も

 まだやっていないこと
  Jenkinsから実機での単体テストの自動化
  ソースコードレビュー
   Gerritなど...

質問による回答

・自動での実機テストで構想はあるのかどうか?
・どういう理由で実機テストが拒まれているのか?
  用意するのが大変
  パフォーマンスの問題(実行速度や転送速度)重たくなりがち

 モバイルの人たちも苦労している
  AndroidはJenkinsで管理
  スレーブにiPhoneをつなげてチェックするなど

 Androidのテスト環境は進んでいるらしいが..

『キャノンにおけるJenkinsへの取り組み』

キャノン株式会社 デジタルシステム開発本部 ソフトウェア検証室の馬場さんのお話で社内にJenkinsを導入するまでに苦労したことや実際の構築内容をお話されました。

社内共通のデジタルシステム開発への導入

 社内共通のデジタルシステム開発に限定してJenkins導入の実施
  800名のうち約半分がソフトウェア屋さん

  2010年:Jenkinsの導入
  2011年:本部内向けにセミナー実施などして広めていった
  2012年:内製のプラグイン開発など

 SummaryReportプラグインについてなど

Jenkinsの環境について

 概ねチームごとにマスターを分散
  他のチームの影響を受けない受けない方が良い
   実行時のセキュリティー面を考慮
  ※うちも今1つのサーバ上で動いているけど分けたほうが良いんじゃないかな?本格的にテストを導入するなら

 基本的にマスターでビルド禁止(組み込み系の場合)
  マスターの構成は柔軟にしておく
  テスト実行環境に専念するため

 最近は、マスターを同じサーバに入れておく
  テスト環境はスレーブとして違う場所に

 ・LDAP?
 ・KVMベースのVMプール?

プラグインについて

・SummaryReportプラグイン
 ビルド全体のテスト結果のサマリー
  =>詳細は、デフォルトで吐き出す情報

 ツール×レポートの種類
  単体テスト エラー検出(メモリーリーク) コードカバレッジ 静的チェック コードメトリクス

 カスタムレポートプラグイン 

・Lcovの設定
 各種レポートのサマリーを表示

 htmlPubliシャブ
 ダッシュボードビュー
 履歴レポート

テスト結果の表示

 テスト結果として
  テスト成功数
  テスト成功数
  行カバレッジ
  行に対するステップ

 1つのジョブだけでなく複数のジョブのテスト結果をまとめて閲覧できるようにしている

 クリーンビルド?
  カスタムワークスペースの利用がけっこう多い
   成果物の受け渡しが足りていない

 テストファーストではなくてもテストセカンドで
  ※コードと同時にテストを書く
  ※テストラストにだけはならないように!

質問に対する回答

・事業部に展開できていない理由
  宣伝できていない部分も有るが....
  チームの数が多い
  事業部はある製品に人が多い

・テストやビルドが回っている感はあったが入れる前と後でなんか変わったことはあったか?
 Jenkins入れる前は内製のツールが合ったが情報がないしGUIが難しかった...
  Jenkinsは情報があるからユーザが自分から調べて出来る 
  興味が湧いてモチベーションが上がっていた

・環境を作るのに大変だったこと
 CentOSでマスター環境を用意
  Jenkinsの設定とworkspaceの設定など
  rsyncで実施

・Jenkinsボートはいつ公開されるの?
 ライセンスだけでも使えるようになればいいのになぁー^^
  財務の関係で厳しいw

『Jenkinsを使うようになったきっかけとEclipseでの簡単にビルド』

@atottoさんによる発表で、Jenkinsの便利なプラグインについてやEclipseでビルドを実行するお話でした。

発表資料:http://www.slideshare.net/atotto/jenkins-study720130128

1開発のお話...

 C++のビルド&テスト
 Sphinxで快適ドキュメントビルド(ドキュメント自動化)
 ☆Twitterにある

 ビルド作業が手作業であった
  Jenkins入れるなら開発の初期でやったほうが良いよ!

 Jenkins = すごいCrontab
 Eclipse CDT
  C++のためのEclipse

 Java => AntとかMaven
 C++ => Makefile
  でも面倒...

 コマンドラインでプロジェクトをビルで出来る
  Eclipse CDT のHeadless Buildを使えば出来る

  http://htn.to/iyFo9q に書かれている

 ビルドマシンにはEclipseさんとJenkinsが入っているイメージ!!
 google testのコードを入れてそれもビルド&テスト実行
 カバレッジ計測は、gcovで行なっている

使っているプラグイン

・TO DO管理
 Task Scanner
  コード中にTODOタグを集計
   TODOタグをコードに埋め込むと表示されるようにしている

・ログ解析
 Warnings Plugin
  警告解析や自分で定義して解決できる

困っていること

 テストの完全自動化
  製品に組み込む(実機ベースになってしまうところ)
  シリアル通信

  WebインターフェイスはSeleniumの使用

 今後やりたいことお
  eXtreme Feedback Device
   楽しい開発を進めて行きたい

  RaspberryPi
   Jenkins + RaspberryPi + ?を使ってやりたい

以上、エンタープライズ系のお話が中心でしたがWeb系にも活かせるお話が盛りたくさんでした。
と同時に、自分にはまだまだ難しいと感じたため、もっとJenkinsについての勉強やそもそもテストの書き方について勉強していこうと感じることが出来た勉強会になりました。

まとめWiki:https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=65670538

【勉強会】ゲーム開発におけるScrum実践例

2012年10月17日にGMOで行われた、アプリ制作勉強会の参加メモです。


アプリ制作勉強会

http://atnd.org/events/32706

株式会社ゲームポットの佐藤 洋三 (さとうようぞう)さんが「ゲーム開発におけるScrum実践例」という題名でお話されました。

資料:http://www.slideshare.net/yoozoosato/20121017gmo-your

Scrumを取り入れるにあたって

・Scrumを目的に開発を行うのは良くない
・ゲーム開発を楽しくすることが目的でScrumは手段

Scrumとは?

 半分以上が知っているけど知っているけど未挑戦の人が多い

・Scrumの概要
 Scrum=フレームワーク
 創造的に価値を生み出すもの
 スプリントというキーワードが重要
 小さいサイクルで遊べるから状況変化に凄く強い!!

  例:2012年5月にあったところ
   消費者庁がコンプガチャはまずいと言い出した
   4月からコンプガチャを作ると決めてあのイベントを迎えたら・・・大変

   「状況に変化できるのは凄く大切」

 動くもの遊べるものが積み上がっていく
 ※紙のドキュメントで楽しさが伝わるならそれは小説とかでも良い
 ※実際に遊んでみないと楽しさなんてわからない

ゲームポットでのScrumの役割

・[PO(プロダクトオーナー)]
  ちゃんと動いている人はほとんどいなかった
  プロデューサーにPOになってもらいたい願望
  POを明示的に立てないままプロジェクトを立ててそんなに上手くいかなかった
  ※POを立ててその人にPOのしごとをしてくださいというのは結構大変

  POの役割の表
  ・やることが多い
  ・全責任を追わなければならない = 情熱が凄く大切
  ・部署またぎなどをするとちょっとやりずらいところも...

・[開発チーム]
  2〜6人で編成
   通常3人未満は良くないと書かれている
   ※人と人との相互作用が少なくなってしまうから
   しかし,ゲームポッドでは2人でもやっている
   プログラマ+デザイナで行なっている

・[SM(スクラムマスター)]
  3名のスクラムマスターがいる
  1つのプロジェクトに1人は必ずいる!(掛け持ちで発生している)
  
  スクラムマスター兼任の問題
  ・Scrumの会議が大変になる
  ・オーバーヘッドが大変
  ・佐藤さんは3つを兼任 15分の朝会×3回が
  ・スプリントの計画が結構たいへん
  ・兼任する際はスプリントの開始をずらす
  ※スプリント計画ミーティングが被らないようにする

ゲームポットでのプロダクトバックログ

・プロダクトバックログ (スクラムマスターが持ち主)
 「〜〜として〜〜が欲しい」という受け入れ条件を記述する
 
 Q.管理方法で一番管理しやすかったのは?
  ※色々なツールを使ってみた
  ・GoogleDocsで行えると複数人で作業が出来るから効率が良い
  ・「PIVOTAL TRACKER」 1人なら無償だがグループだと有償

 A.結論

 紙最強!!

 ・1枚の紙にやりたいことリストを描いているだけ
 ・印刷して裁断するのもあり!

計画のお話

 全体の計画をたてる = プロダクトバックログ
 「プランニングポーカーをメイン」に「Tシャツサイズ」をたまに利用

 ・初日にスプリントの計画 約2〜4時間くらいかかる
  ※プロジェクトの開始時期をずらさないとScrumマスターは大変

 ・プランニングポーカーは,相対的に見積る
  ビルの図の説明がわかりやすい!!

 見積もることが大切ではない

 ズレを話し合い、認識を合わせることが目的

 ・簡単に行いたい時はTシャツサイズ
  S M L XLでサイズで見積もる
  しかし,ざっくりとなので,時間見積が難しい

 ・タスク分割
  ストーリーに対して
  ・仕様を決める
  ・テーブルの作成・設計
  ・ロジック実装
  ・演出
  ・見積りは時間単位で出す(h)

デイリースクラムについて

 2〜6人のチームで行い常温を維持するため行う
 「共有する内容」
 ・昨日やったこと
 ・今日やること
 ・困っていること
 ・バーンダウンチャート

 デイリースクラムは、

  開発同士の間で情報共有することが目的

 スクラムマスターへの報告を上げてもらうミーティングではない

 ※デイリースクラムでは、問題対私達のという形で向き合う図が良い!!
 ・ホワイトボードに向きあって問題に対して議論しようという考えかた  
 ・朝会の時はホワイトボードに向かって行う
 
※バーンダウンチャート
 .見積りの全ての時間が縦軸 日付
 ・なんで失敗したかを考えるのもスクラムマスターの仕事

振り返りについて

 スプリント(ゲームポットでは2週間)が終わると...
 ・早い段階で振り返り
 ・KPT(KeepProblemTry)を使って行う

 Wikiか付箋に描いている
 ・Keep   : 今回のスプリントで良かったこと
 ・Problem : 今回のスプリントでの問題点
 ・Try   : 今までやってないけど挑戦したいこと

質問

・機能とデザインは密接な関係があるが,タスクとして分割する際にはどのように行なっているのか?

・なぜバーンダウンチャートがおかしくなったのか?
 ※自分たちもScrumを行なっているが、タスクに分解して時間の見積りはするがあまり時間の管理が出来ていないのが現状

・通常3人未満は良くないと言われていが2人で開発を進めていて不都合などはないのか?

.プログラマ+デザイナで行なっている どういう感じで開発を行なっているのか?

・KPTのやり方は、どのように行なっている?
 ※みんなで付箋に書いて1人ずつ発表してそれをまとめるという形式をとっている

以上

自分たちもScrumで開発を行なっていたので、凄くためになるお話でした。

詳しくは、佐藤 洋三 (さとうようぞう)さん発表のスライドを御覧ください。

資料:http://www.slideshare.net/yoozoosato/20121017gmo-your