AWSソリューションアーキテクト プロフェッショナルの勉強方法【cloudpack 大阪 BLOG】

先日、AWSソリューションアーキテクト プロフェッショナルレベルに合格しました！

※試験の概要等はこちらを参照ください。aws.amazon.com

受験して分かったことがありましたので綴ります。

どんな感じで問題が出るか

1. 各サービスの特徴を踏まえて、高可用性、高セキュリティ、高いコスト効率の答えを求められます。
2. あり得ない選択肢が出てきたり、解決したい課題が”コスト効率”なら「これ」が一番良い。という感じで選択します。
3. それらを170分間で1問当たり2分程度で回答する必要があります。

つまり、短時間でより良い答えを導き出す必要がある＝各サービスについて理解して且つ活用方法も知っておく必要があります。

勉強方法

で、それらの勉強方法ですが、ドキュメント関連を読むのも大事ですが、それ以外には以下をオススメします。

1. 実際に使う
2. Slideshareで色々な使い方（特にバッドノウハウ）を学ぶ
3. 勉強会で生の声（使い方、事例）を聞く

一番のオススメ

一番は実際に使う事です。

ドキュメント読んだりBlack Beltとかでも学べますが、使ったことないと正直頭に入りません。。

一度でも使う事で全体像が見えてきたり、パラメータの意味が理解出来たりします。

注意点

ただ、闇雲に使っても「作ってオシマイ」なので、何か目的を持って（今の課題や利用しているシステムを無理やりAWSサービスに置き換える妄想して）作ると試行錯誤して作れると思うので、学習効果が高く理解が進みます。

最後に

AWSはWeb上に沢山の情報がありますので、先人の知恵をお借りして効率良く学んでいきましょう！

そして学んだ所に感謝の意を込めて貢献して行きましょう！

Let's AWS Life!

作業を抽象化するRundeck 〜もはや幸せしか生まない〜【cloudpack 大阪 BLOG】

まぁ、別にJenkinsでも似たようなツールであれば何でも良いんですが、
RundeckのUIがイケてる感じがしたので選んでみました。

Rundeck の機能

Rundeckは主に以下のような機能を備えています。色々出来る万能ツールです。
ですので、色々な用途で使えるかと思います。

• コマンドの分散実行
• 拡張可能な実行システム（デフォルトでは SSH）
• マルチステップワークフロー
• ジョブの定義と実行（即時 or スケジュール)
• コマンドとジョブを実行するための GUI
• ロールベースの ACL（LDAP/ActiveDirectory 連携可能）
• 履歴とログ監査
• 外部のホスト管理ツールとの統合(open integration)
• CUI インタフェース
• Web API

考えてみた用途

障害時の調査・復旧手順をRundeckに入れる。

何が良いか。

1. 今までの複雑な手順書ベースの作業がボタンを押すだけの単純作業となり、その結果、

• 素早い調査・復旧となり品質向上します。

• 誰でも同じ品質で実行できます。（オペミス減ります）

• 複雑な手順書を見ながら実行する。と言ったネガティブ感が無くなります。

• 工数も削減出来る（か、どうかはRundeck化工数次第です。*後述）

2. 実行結果（標準出力）も残せるので、証跡が残せます。SOC2的にも良い？

• 誰がいつどんな作業をして、どんな結果だったか。とか残ります。

• お客様にも作業記録と結果を時系列で説明が出来ます。

• AD連携可能なので個人識別可能です。

3. API連携可能っぽい？（確認中）

• 監視ツールとかAPI経由で実行可？
• SlackとかBacklogに自動投稿可？
• それができたら検知 => 対応 => 報告も自動化可能？（やりすぎ？）

特に良いこと

多種多様の環境下で力を発揮します。
特に数百のお客様やプロジェクト、数千のインスタンスを抱えている環境だと、個毎に環境や前提が異なります。
統一しようとしても、難しい。そんな場合に、Rundeckはそれらの環境を抽象化してくれます。

Rundeck無いときー

Rundeck有るときー

これは作り込みさえしておけば、どんなに環境が増えてもやることは同じ（ボタンを押すだけ）で「何が良いか」の恩恵が受けられます。

注意点

Rundeckに色々な手順を突っ込むのは良いのですが、あまり数を突っ込んだり、複雑な手順を入れるとカオス状態になります。
それでは手順がクローズされただけで、誰もメンテ出来ない（いや、断固としてしたくない）状態になります。
複雑な手順＝そもそものシステム設計が複雑。ですので、設計段階の問題になりそれがカオスを生み出します。
複雑に作るよりシンプルに作る方が難しいですが、ステークホルダのWin-Winを考え、シンプルな設計を心がけましょう。

まとめ

うまく作ればコスト削減にも繋がり、ステークホルダとWin-WInになるかもしれないですね！
と、言う事で、Rundeckオススメです！

Enjoy! Rundeck Life!!

AWSサポート利用時の注意事項 by OpsJAWS #1より【cloudpack 大阪 BLOG】

先日、OpsJAWS #1に行ってきて参考になった事がありました。
ブログにするまでが勉強会ということで。

1. AWSサポート利用時の注意事項

この業界の方は知り合いに「パソコンが動かなくなった！どうしたらいい？？」とか聞かれる事が多いと思いますが、
「どういうエラーが出てる？どこまで起動してる？」とか「キャプチャ送って」とか、色々聞き返す必要がありますよね。

AWSサポートも同じで、ざっくりとした問い合わせだと確認事項が多くなったり、
分かっている情報だけで調査を始めるため時間がかかるそうで、そのため、当たり前ですが
情報は省略せずには可能な限り提示して欲しいとのこと。早期解決に繋がります。

それらを踏まえて、以下のような情報を伝えれば早期解決に近づくと思います。
（後述しているURLを見たらわかりますが、サポートの方は幅広い知識を持つスペシャリストですので、
情報があればあるほど良いです。）

したいこと	具体的に
問題	何が問題なのか
再現手順・再現コード
事象発生日時、発生頻度
調査対象のリソースを特定出来るもの	インスタンスID、ELB名、RDS名など
アクセス元の情報	EC2、VPN経由、Internet経由など
ログ・画面キャプチャ	可能な限り省略せずに

2. デバッグログ

CLI利用時は --debug オプションを付与して再実行した結果を添えると、よりスムーズに調理頂けるようです。
SDKに関しても同様にデバッグログを送付する事で素早く調理頂けます。

3. AWS Support API

APIでサポートを利用出来るのですが、Dry-Runが出来ないそうですので、
プログラムに組み込む時は事前にサポートに連絡の上で対応ください。とのこと。
（事前連絡が無い場合、中の人から電話がかかってくるかもしれませんw）

4. AWS CloudTrail

これを有効にしないと調査にすごく難航されます。っていうか、有効にしてない人なんて居ませんよね？

という事で、AWSサポートを是非活用してください！との事でした。

PS. こちらにも中の人の熱い記事があるのでご一読くださいな。

codezine.jp

運用視点でのAWSサポート利用Tips from Noritaka Sekiyama

www.slideshare.net

Datadog agentの設定方法【cloudpack 大阪 BLOG】

Datadog agentはインストールするだけで、自動的にCPUやメモリなどのメトリクスを取得してくれますが、
少し手を加えることでもっと沢山の情報をDatadogに集めて、”見る”事が出来ます。今回はその設定方法を記載します。

1. インストール

一発でインストール・自動起動設定などが出来ます。超簡単です。

※API_KEYを埋め込む必要があるため、Datadog管理画面（[Integrations]-[Agent]）より自OSを選択の上でコマンドラインをコピーして下さい。

DD_API_KEY=ABCDEFGHIJKLMNOPQRSTU bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/dd-agent/master/packaging/datadog-agent/source/install_agent.sh)"

2. 設定ファイル確認

本題の設定方法です。
インストールすると''/etc/dd-agent/''というディレクトリができるので、 /etc/dd-agent/conf.dに移動します。

cd /etc/dd-agent/conf.d

すると以下のサンプルファイルが生成されています。

activemq.yaml.example
activemq_58.yaml.example
activemq_xml.yaml.example
agent_metrics.yaml.default
apache.yaml.example
btrfs.yaml.example
cacti.yaml.example
cassandra.yaml.example
couch.yaml.example
couchbase.yaml.example
directory.yaml.example
disk.yaml.default
docker.yaml.example
elastic.yaml.example
etcd.yaml.example
fluentd.yaml.example
gearmand.yaml.example
go_expvar.yaml.example
gunicorn.yaml.example
haproxy.yaml.example
hdfs.yaml.example
http_check.yaml.example
iis.yaml.example
jenkins.yaml.example
jmx.yaml.example
kafka.yaml.example
kafka_consumer.yaml.example
kyototycoon.yaml.example
lighttpd.yaml.example
marathon.yaml.example
mcache.yaml.example
mesos.yaml.example
mesos_master.yaml.example
mesos_slave.yaml.example
mongo.yaml.example
mysql.yaml.example
nagios.yaml.example
network.yaml.default
nginx.yaml.example
ntp.yaml.default
pgbouncer.yaml.example
php_fpm.yaml.example
postfix.yaml.example
postgres.yaml.example
process.yaml.example
rabbitmq.yaml.example
redisdb.yaml.example
riak.yaml.example
riakcs.yaml.example
snmp.yaml.example
solr.yaml.example
sqlserver.yaml.example
ssh_check.yaml.example
supervisord.yaml.example
system_core.yaml.example
system_swap.yaml.example
tcp_check.yaml.example
teamcity.yaml.example
tokumx.yaml.example
tomcat.yaml.example
varnish.yaml.example
vsphere.yaml.example
win32_event_log.yaml.example
windows_service.yaml.example
wmi_check.yaml.example
zk.yaml.example

それでは、実際の設定をしてみましょう。

3. 設定の有効化

基本的には/etc/dd-agent/conf.dに移動し有効化したいファイルをリネームし、中身を修正する。だけです。

cd /etc/dd-agent/conf.d
mv apache.yaml.example apache.yaml
vi apache.yaml

4. 反映

最後はいつものプロセスを再起動して完了です。

service datadog-agent restart

正常に値を取得出来ているか確認しましょう

service datadog-agent info

5. 以下は有用そうなものをピックアップしています。

• 注意点： yamlファイルを修正する際にTabは使わず半角スペースを使って下さい。

tcp_check.yaml

■ 内容：ポート監視
■ 修正方法：

• name: 対象の名前を定義（httpd/tomcatなど)
• host: 接続先を定義（RDSなどの外部も可）
• port: 接続先のPortを定義
• timeout: タイムアウト値を定義

- name: httpd
   host: localhost
   port: 80
   timeout: 1

process.yaml

■ 内容：プロセス監視
■ 修正方法：

• name: 対象の名前を定義（httpd/tomcatなど)
• search_string:: 対象のプロセス名を定義、部分一致、複数指定可
• critical: 以下の例は1以下 or 7以上でCritical
• warning: 以下の例は2以下 or 6以上でWarning

  - name: ssh
    search_string: ['ssh', 'sshd']
    thresholds:
      critical: [1, 7]
      warning: [3, 5]

apache.yaml

■ 内容：Apacheの状態取得(server-status)
■ 修正方法：

• 以下のようにmvする
• (httpd.conf) mod_status がインストールされ、そのモジュールがExtendedStatus付きで有効化されている
• (httpd.conf) localhostからserver-statusが参照出来るようにする

mv /etc/dd-agent/conf.d/apache.yaml.example /etc/dd-agent/conf.d/apache.yaml

■ 取得できる値

apache.net.bytes
apache.net.bytes_per_s
apache.net.hits
apache.net.request_per_s
apache.performance.busy_workers
apache.performance.cpu_load
apache.performance.idle_workers
apache.performance.uptime

http_check.yaml

■ 内容：URL監視
■ 修正方法：

• name: 対象の名前を定義（Webサイト名など)
• url: 監視先URLを定義
• timeout: これを超えると遅延している。という値を定義（秒）
• 補足
• Basic認証やらオレオレSSL突破など色々オプション有り

- name: www.example.com
  url: http://www.example.com
  timeout: 4

mysql.yaml

■ 内容：MySQLの状態取得（AWS-RDSでも有用）
■ 修正方法：

• server: localhost or AWS-RDSの場合はエンドポイント
• user: MySQLのユーザ名
• pass: MySQLのパスワード
• port: MySQLのポートを定義（通常は3306）
• AWS-RDSの場合は以下も設定（CloudWatchで取得した値を紐付けされる）
• dbinstanceidentifier:RDSのdbinstanceidentifier

- server: mysqlrds.blah.us-east1-rds.amazonaws.com
  user: my_username
  pass: my_password
  port: 3306
  tags: 
    - dbinstanceidentifier:my_own_instance

■ 取得できる値

mysql.innodb.buffer_pool_size
mysql.innodb.data_reads
mysql.innodb.data_writes
mysql.innodb.os_log_fsyncs
mysql.net.connections
mysql.net.max_connections
mysql.performance.created_tmp_disk_tables
mysql.performance.open_files
mysql.performance.queries
mysql.performance.questions
mysql.performance.slow_queries
mysql.performance.table_locks_waited
mysql.performance.threads_connected

mcache.yaml

■ 内容：Memcachedのパフォーマンス取得（AWS-Memcachedでも有用）
■ 修正方法：

• url: localhost or AWS-Memcachedの場合はエンドポイント

- url: localhost

■ 取得できる値

memcache.bytes
memcache.bytes_read
memcache.bytes_written
memcache.cmd_get
memcache.cmd_set
memcache.connection_structures
memcache.curr_connections
memcache.curr_items
memcache.evictions
memcache.get_hits
memcache.get_misses
memcache.limit_maxbytes
memcache.pointer_size
memcache.rusage_system
memcache.rusage_user
memcache.threads
memcache.total_connections
memcache.total_items

redisdb.yaml

■ 内容：Redisのパフォーマンス取得（AWS-Memcachedでも有用）
■ 修正方法：

• host: localhost or AWS-Memcachedの場合はエンドポイント

- host: localhost

■ 取得できる値

redis.aof.buffer_length
redis.aof.last_rewrite_time
redis.aof.rewrite
redis.aof.size
redis.clients.biggest_input_buf
redis.clients.blocked
redis.clients.longest_output_list
redis.cpu.sys
redis.cpu.sys_children
redis.cpu.user
redis.cpu.user_children
redis.keys.evicted
redis.keys.expired
redis.mem.fragmentation_ratio
redis.mem.lua
redis.mem.peak
redis.mem.rss
redis.mem.used
redis.net.clients
redis.net.rejected
redis.net.slaves
redis.perf.latest_fork_usec
redis.pubsub.channels
redis.pubsub.patterns
redis.rdb.bgsave
redis.rdb.changes_since_last
redis.rdb.last_bgsave_time
redis.replication.last_io_seconds_ago
redis.replication.sync
redis.replication.sync_left_bytes
redis.stats.keyspace_hits
redis.stats.keyspace_misses

以下は検証中

• fluentd.yaml
• ssh_check.yaml
• postfix.yaml
• system_core.yaml
• system_swap.yaml
• network.yaml.default
• php_fpm.yaml
• tomcat.yaml
• postgres.yaml

Let's DD Life!!