新人アドテクエンジニア向け学習コンテンツ
インターネット広告の会社に勤めているのですが、5月に配属されてきた新卒のエンジニアの卵に、「どうやって勉強すればいいですか？」と聞かれたのと、以前何人かに「どうやって情報収集していますか？」と聞かれた経験があったので、まずは参考になるサイトをジャンルごとにピックアップしてみました。
業務（広告、マーケティング）系
- Markezine
アドテクに関わる人は、特に下記コンテンツは役に立つと思います。
- ここからはじめよう！アドテクノロジー基礎講座一覧
- Web担当者Forum
エンジニア向けの技術コンテンツではありませんが、広告効果指標の用語説明など、 ネット広告運用の業務知識として役立つ記事が満載です。
- 業界人間ベム
これは何気に自社で運営しているブログで、ネット広告業界の著名人、横山隆治 氏が書いています。 このブログも結構この界隈では有名らしいです。
また、こんなふうにまとめてくれているところもありました。
- NAVERまとめ 新人webマーケティング担当者にオススメのサイトまとめ
僕はNAVERまとめでまとめたことはありません。。
ITニュース、技術ポータル系
エンジニア向けの技術系コンテンツが豊富なポータルサイトがよく使えます。 IT系出版社が運営してるのが多いです。
- gihyo.jp
上記3つは実装系の話題が多いサイトでかなり使えます。
- ITPro
エンタープライズ系のニュース、コンテンツが多いですが、 ここは技術情報（コマンドリファレンスなど）も多いです。
- TechCrunch
Webスタートアップ系のニュースが多いとこです。
ニュース系の話題や個別の記事は、自分から行って色々見るのももちろんいいですが、 だいたい検索流入するか、FB、Twitter、メルマガから気になるのを見るという使い方が良いような気がします。
ブログ系
- Qiita
アカウント含め基本的に個人ですが、今や技術系の話題はググると高確率で当サイトがヒットします。 個人の技術ネタのストック先は普通のブログよりこっちに書く方が反応が良いくらい。 かなりの数のエンジニアが寄ってきていると思ってよいです。
* Web系企業の公式ブログ
各社のエンジニア達が書いているブログがここに集まっています。 気になるものをブックマーク、いいね！、フォローなどしてください。
Q&Aサイト
プログラムに関するあれこれを聞くと、「お、知ってるぜ」と思ったエンジニアが返してくれるQ&Aサイト。
- stack overflow
技術Q＆Aサイトの有名どころです。 英語が本家ですが、日本語版もいつからかできたみたいです。
- teratail
stack overflowの日本語版の代わり？と思いましたが、 目指しているところは「勉強会」だそうで、ちょっと違うコンセプトのようです。
回答が最速52秒で返ってきたとか。
動画学習コンテンツ
- ドットインストール
動画でプログラミングの学習ができるありがたいサイトです。
フォローしておくべき人
ここまで挙げたのはサイトですが、情報収集は書いてある場所よりも「良い情報を知っている人」を知っていること、いわゆる "know who" が重要という側面もあるので、その参考に少しだけ以下もメモっておきます。
- 2015年新米エンジニアがフォローすべきツイッターアカウント50選
- Web担当者必見！今すぐフォローすべきWebマーケティング界隈の著名人Twitterアカウント51選
- 今すぐフォローすべきAWS界隈の素晴らしきエンジニア達 #jawsug ｜ Developers.IO
http://dev.classmethod.jp/cloud/aws/lets-follow-aws-engineers-now-2014/
JAWS DAYS 2015 参加レポート
JAWS DAYS 2015 に参加してきました。
昨年は都合が悪く行けなかったので、初めての参加。
会場の雰囲気はこんな感じ。
人気のセッションは立ち見だったので簡単になってしまったけど、以下、備忘のためメモアップします。
※後日資料が公開されたりするので随時更新しようと思います。
スマートニュースの世界進出を支えるログ解析基盤 on AWS
立ち見で途中から入ったのであまり全体の流れがメモできず。 気になったところ＋考察という形で。
インフラ構成について
・ストレージとアプリケーション層は分離すべき ・分離することでクラウドらしい設計になる
Azkaban
[特徴]
- ジョブ管理がしやすい
- ジョブをコードで定義
[デメリット]
- Azkabanのexecuterは一代しか持てない
http://sstd-bigdata.blogspot.jp/2014/09/azkaban.html
http://d.hatena.ne.jp/wyukawa/20150110/1420889758
初めて聞いた。ジョブ管理ツールはこれというものがなかったので、使ってみたい。
Presto
Facebookで開発されたクエリ実行エンジン。 今はTreasuredataなどでも使える。 自分も会社で使ってます。
クエリ実行エンジンでDBそのものではないから、 複数のデータソース（MySQL&Hiveなど）のjoinができる →以下のスライドが理解の助けになるはず。
Chatio
バックエンドが切り替えられるダッシュボード。 フロントエンドの作り込みが不要 見やすい、キレイなので毎日見る気が起きる。
BigQuery
すごい。あまり深いこと考えずにクエリ投げても返ってくるが、 データを扱う技術は追いかける必要があると思うので、使い分けが必要と思う
所感
成長とともにインフラもちゃんと成長してきているのが分かり、尊敬。 設計思想などは現場の実感が込められているのが伝わってきました。
まる見え、AWS!! ～CloudTrailとConfigからわかるAWSオペレーションのすべて～
CloudTrailはまだちゃんと使えていないので、ノウハウなど得られるといいなと思い。
Cloud trail
AWS APIの呼び出し履歴が取得出来るいわゆる監査ログ記録・管理のためのログ送信ツール。
AWSセキュリティ編～CloudTrailの活用～ – ナレコムAWSレシピ
Management Consoleの操作などNon API call のイベントも取れる JSON形式での出力でどうするか？というのは使い方次第。
「現在有効にしていない人は今すぐ有効化してください！」というほど大事なサービス。
使い道
- アラート検知
- 文字列検索
- 可視化
Cloud trail のログをcloud watch logs に連携 メトリックフィルタを作って特定インスタンスタイプが作られたらアラート飛ばすなど クラウドformationでメトリック作れるのが出来た。楽にできるはず。
CloudSearchに入れてログを検索したい！
例えばあらかじめ拾いたいメトリックスをフィルタにして、SNS,SQSを使って Elastic searchにいれてKibanaで見るなどの仕組み
Aws config
設定変更がどのインスタンスやセキュリティグループと紐付いてるかを一気に取れる 既にLog strageなどいくつかの製品と連携している 例えば古いAMIから上がっているインスタンスはどれか？などもわかる
所感
CloudTrailって監査ログってイメージだったのだけど、積極的に可視化するという思想はあまりなかったんだけど、やっぱりちゃんと検知・分析できる仕組みを構築しないと、と思いました。
www.slideshare.net
「OpsworksでDevOpsを感じよう」、「OpsWorkの仕組みと活用方法の紹介」
続けて聞いたのでこちらはまとめてメモ。
OpsWork
- 2013年2月よりローンチしたサービス
- プロビジョニング、設定管理、デプロイメント、監視及びアクセス制御など
- 複雑なアプリケーションライフサイクルのための管理ソリューション
OpsWorksで設定管理に関係するaws項目
EC2,VPC,ELB,EBS,RDS,IAM
スタック
OpsWorksのトップエンティティ、全体の設定を行うところ
スタック作成の準備
- リージョン
- VPC
- EC2 などなど
上記ができていれば、コンソールからポチポチ デフォルト設定をする （詳細作成の際に変更していくことは可能】
最初にNWを作って、OpenにしておかないとOpsWorksのエージェントが通信できない
レイヤー
OpsWorksには「レイヤー」が必要。なんすかそれ。。 (例) * HA Proxy * App Rails App Server, PHP AppServer * DB ** MySQL などなど
インスタンス、スケールタイプを指定
OpsWorksを使うと良くなるところ
EC2起動、ソフトウェアインストール、デプロイの自動化
Capistranoなどのツールを使えば自動化出来るが、AWSのマネージド機能ではできないので利用価値はある
OpsWorksで起動したインスタンス内部で起動するOpsWorksエージェントがChefレシピを実行可能
OpsWorksエージェントからOpsWorksエンドポイントに対してPolling
- OpsWorksによって発行された一連のコマンドを取得して、Chef solo（Chef Zero）でレシピを実行 ※Chef Serverと通信するわけではない。あくまで単体実行
- Chefのレシピやアプリケーションコードは指定したコードリポジトリから展開（Git等）
OpsWorksで実行可能なコマンド（2種類）
- スタックコマンド
スタック全体の構成を変更・管理するためのコマンド、MCから実行可能
- エージェントコマンド
基本はスタックコマンドを使う
- スタックコマンドを使って、リモートから任意のタイミングでインスタンスにコマンドを実行可能
→MCから指示するだけ
- レシピを自動実行させるために、ライフサイクルイベントを利用 （Setup,Configure,Deoloy,undeploy,shutdonw) ←Chefのビルトインレシピ
カスタムレシピをもちろん利用可能
どうやってライフサイクルイベントを利用するの？
→最初のインスタンスを起動すると、Setupが呼ばれる→Deployが走る→全てのレシピが成功したらConfigureイベントが呼ばれる
利用例
- 運用関連タスクの自動化の例
- セキュリティ脆弱性に対するソフトウェア・パッケージアップデートをChefレシピから自動で展開するなど （再起動とか、Perlパッケージとか、気にしなくて良い構成にしてないとダメよね。。）
www.slideshare.net
www.slideshare.net
- OpsWorkのハンズオン資料 www.slideshare.net
ランチ
参加費1000円は払ってるものの、タダ飯が食えるという太っ腹なおまけ付き。
ランチセッションもやってたけど、あまり見たいのがなかったのでゆっくり食べてました。
腹ごしらえして、さぁ午後のセッション。
MMO RPG on AWS
ソリューションアーキテクト今井さんのセッション！ いつもお世話になっております。
今回は韓国のSAユンジンさんとの共同セッション。 ユンジンさんが英語でプレゼンし、今井さんが日本語で訳すというチャレンジングなセッション。 カッコええ。
NexonoのMMORPG環境の運用事例の紹介をしてくれました。
MMORPGとは
- Massively Multiplayer Online Role Playing Game
- 非常に多数のユーザが同時接続し、インタラクションしながら進めていくゲーム
MMORPG on AWS needs - Massive message handling -
- 膨大な数のメッセージのハンドリング
非常に多くのユーザが同時に接続して、魔法を使うと他のユーザにダメージが出るなど、同時インタラクション要素が非常に多い(N - N)
- 1台→スケールさせるためにはどうするか？
オンプレだったら、TCP,UDPで独自プロトコルの上でマルチキャストを実現 ** が、AWSではマルチキャスト、ブロードキャストはサポートしてない。どうするか？
PubSub (Publish-subscribe) モデルを使う ** SNS,Elasticache,RabbitMQなどを使って実現
ZeroMQを使った C,C++実装、速い No brokerノードの仕組みなので、No SPOF
Game server load balancing
1つワールドを実現するには、サーバ毎にセッションを分ける等を行っていたが（どっかで昔聞いたような・・・） それをどうやって複数サーバで1セッションを実現するか。
1つのGameのMap上で離れた島（国？）間はあまりインタラクションが発生しない。別々のセッションにできる
- エリアの特性によって、ユーザの偏りがあるためロードバランス上課題となる
- Low densityエリアは1台のサーバで広くカバー
- High densityエリアは複数のサーバでカバー
- ダイナミックにサーバをAllocationさせる
- 複数のサーバでカバーしているところはいかにインタラクションさせるか？
- エリア内でユーザが大きくなってきてしまったら、Geo locationで分割
- 分けたサーバ間でデータをsync
Minimize data sync
データ同期を最小化するための仕組み
例：植物、動物、人（ユーザ）が登場人物 それぞれを別サーバに切り出し、マップ上の同じ場所で動きがある部分（オーバラップしたところ）だけ インタラクション（同期）する
Ghost abstraction
以下に低レイテンシで大量のI/Oを実現するか
- MMOの各ユーザの持つデータは様々
全てDBに格納する必要がある
基本は非同期I/O
- NoSQLを使う
- DynamoDB
- MongoDB
- CouchDB
RDBでなくNoSQLな要因？
- 今更だが、DBスケールアップで限界が来るとビジネスが頭打ちになる
スケールアウト可能なアーキテクチャ
多くのアイテムを如何に高速に検索して返すかというのが重要なポイント
- NoSQLと CloudSearch or ElasticSearch を用いる ** EC2-ElasticSearch-NoSQL
(この連携の仕方がよく分からん。。)
まとめ（抜粋）
- Ec2のエンハンスドネットワーキングはとても優秀
- NoSQLと検索の組み合わせ
- データ同期の平均所要時間を縮めるために非同期I/Oを利用する
- 分散環境においてゲームキャラクタ同士のインタラクションを実現するためにRPCを利用する
Q&A
- ブロードキャスト、マルチキャストをサポートする気があるか→今のところプランなし
- ちなみに使いたい人は？→会場では少数
そんな話題にフォーカスすること自体、自分にとっては少々驚きでした。
所感
ゲームの運用をここまで掘り下げて聞けたのは初めてだったのでとても興味深かった。 この業界は本当にテクニカルで難しそうだけど、面白そうだな、と思いました。
開発するように運用するインフラ （Kaizen Platform）
超人気セッションに。naoya氏の露出の影響が大きいためか、皆名前を知っているのだろう。
Kaizen Platformの事業
サイトのA/Bテストをするインフラを提供
- 管理画面
- Js配信
- jsの計測
→jsを埋め込んで、計測する
すべてインフラはAWSを利用 ELB,EC2,RDS,ElastiCache というシンプルな構成
色々とSaaSを使っているので、主にGitHubとCircleCIを使った開発・運用について紹介
Githubでの開発プロセス
- Work in progressでpullrequest（マスターbranchから開発branchを切る）
- 開発
- レビュー レビュー依頼はチャットのBotに出す。 PR内で注意点をいれてmention
E2Eテスト
E2E（End-to-End）テスト
システム全体が正しく動作することを確認するテスト。UIの動作・裏側API・バッチも含めてのテストと言うことか
headlessテスト(自動テスト)
- 本番リリース
QAブランチ
専用branchにマージしてテスト
CircleCI
任意のbranchへのpushを契機にアクションさせられる
- master branchへマージしたらunitテスト
デプロイbranchにいれたらデプロイ
本番デプロイbranchにpullrequestのリストができる
では、インフラは？
- GitHub,CircleCIに、Chefを追加して運用
- できるだけ運用プロセスを開発プロセスと合わせるようにしている
運用プロセスを開発、インフラと合わせることができると、開発側で構成変更したい時にも入りやすくなる
構成管理変更はChef Recipeに書いてpullrequest
リリースもチャットとcircleCIに残るので、このプロセスに乗るだけでドキュメント手書きしなくても履歴が残る
構成変更後はE2Eテストで大丈夫か確認
構築検証、Serverspecでテスト(circleCI)
レシピを作るところ以外はgithub,circleCI,チャットでインフラ運用できる
- この仕組みにしてからサーバログインすることがなくなりました(！)
Kaizenの行動指針
官僚的にならない (×～さんの許可がないと出来ません)
「権威的にならない」(クックパッド) という言葉で気付かされた
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013 － Publickey
- 受理して許可を出す側の人間は権威的になりがち
- 気づかずそうなってる場合もある
大事なこと
- 開発と運用のプロセスを出来るだけ合わせる
- 開発が運用に参加する敷居を下げる
- やろうと思えば出来るという環境 ** 気軽に構成変更のpullrequest出せる
- インフラエンジニア怖くない ** 開発の人からするとそんなイメージもあるので注意
これ、すごい身につまされる指摘だと思う。 自社の現場にいても分かるけど、質問しにくい雰囲気出しているインフラメンバに、恐る恐る質問しに来る開発メンバという構図は結構見かける。 インフラの立場からして、急な作業依頼とかでイラッとすることもあるのは理解できるけど、開発者の方も事前に伝えられない事情はよくある。 （お客さんや連携先の会社の都合とかはもちろんそうだし、そもそも何かの事情で作業をするときに「インフラで対応が必要」ということまで見えている開発者は少なかったりする。）
セキュリティアップデート
チャットからセキュリティアップデート指示 すごい。
yum --security -y update する旨と、アップデートされる依存パッケージなどを記述してpullrequest
- マージを契機に実行
- ただ、再起動があるものなどは同じように実行はできないので、そこは泥臭くやる。（ちょっと親近感ｗ）
運用課題
- CircleCIがボトルネック
- 開発、インフラ(レシピ)、E2Eテスト 全てここを使うので
- テストとかを早く(軽く？)することで頑張る
- あとはお金で解決(今のところ)
他、使っているSaaSの紹介
Bugsnag
- Crash レポート解析サービス
Error Monitoring & App Stability Management | Bugsnag
Pingdom
- 複数の拠点からhttpのエンドポイントをひたすら監視してくれるサービス
このあたりが参考になりそう。 HTTP監視サービスPingdomについて | 稲葉サーバーデザイン
PagerDuty
- 障害時の通知サービス
- Sensuとの連携可能(カイゼンではsensu利用)
- 少人数でインフラ運用するのによい
EC2はもう不要？Lambdaってなにができるの？
まさにLabmdaって何よ？って状態だったので、概要をつかむために聴講。
登壇者
- Webエンジニア(非インフラ)
- AWS歴2,3年
- Node.js１週間
- Labmdaはまだ業務では使ってない
Labmda概要
イベント発生時コードを実行できる (イベントドリブン型のバッチが作れるかな…でもnode.jsでは)
例）画像をs3にアップロードするとサムネイル画像を作って保存
トリガを設定
- 対応するサービスまだ少数
- S3,cloudtrail,DynamoDB,Kinesis
画面から設定できるのはS3のみ
イベントに応じたコードを設定
- 画面上でコードを書く
- 画面からコードをアップロードする
どちらもManagementConsoleで設定可能 (ここでコード書く人いないと思うけど)
料金
- 使用した分のみ
- $0.20/100万リクエスト
- メモリ×実行時間
- メモリ1GB/秒の使用につき$0.00001667
所感
- サーバ不要でイベントドリブン処理が動かせる、という理解ができた
- まだNode.jsのみなので、良い活用事例などはもう少し後になりそう
- 何に使えるか？
- EC2でcronでポーリングして実行するバッチ処理
- Node.jsのapiで作ってあってs3,ec2にインプットがあるもの
各セッション資料まとめ（by dots.)
イベント情報サイトのdots.さんで資料とレポートのまとめページが公開されました。 参加出来なかったセッションの内容はこちらを参照。
EC2起動時の自動セキュリティアップデート（yum update）を無効にする方法
Launch Instanceする際、「Configure Instance Details」の「Advanced Details」にある、 ”User data”に、textで(As text) 以下を入力
#cloud-config repo_upgrade: none
これで、AMIから起動したらPerlのバージョンが上がってた！ ・・・というトラブルを回避。
limits.conf の soft / hard について
soft limit / hard limit の理解について曖昧だったので、おさらいしました。
そもそもOSのどこで設定していたんだっけ、というところから。
◇/etc/security/limits.confに関するメモ
http://open-groove.net/linux/memo-etcsecuritylimits-conf/
定義は明快に書いてありました。助かります。
soft/hardの違いは、softが一般ユーザが変更できる上限値で、hardはrootが変更できる
上限値を意味する。ユーザ名を「*」とすればすべてのユーザに適用される。
とのことです。
ユーザごとの設定で soft / hard が記述できるので、sshの接続数制限とかと似て、softは超過しても、hardまではある程度許される猶予なのかと思いましたが、そうではなく、「各ユーザにて、 ログインして ulimit で（一時的な）変更ができる上限値」 = soft であると。
無理やりsshとの関連を挙げるのであれば、上記URLのページの最後にある、
「sshではセキュリティ確保のため、ssh経由で接続したプロセスに対し、そのユーザーが本来持っている権限以上の変更はできない」
というところでしょうか。
ファイルディスクリプタの制限 については、nginx(worker_rlimit_nofile ※プロセスごとの上限)やMySQL(open_files_limit) などミドルウェアで独自に設定値を持っているケースもあるので、頭に入れておくと、トラブルシューティング時の視点が広がると思います。
◇mysqldのファイルディスクリプタ数
http://studio3104.hatenablog.com/entry/20121030/1351587278
エンジニアのためのミスを減らすチェック方法
1年目の新人に、サーバのキー（ハッシュ文字列）20個あまりを ファイルサーバに保管するようお願いしたのですが、 文字列のキーをコピペしてく作業なので、きっと間違いが出ると思い、 他の人にもチェックしてもらったところ、やはりミスがありました。
具体的には、キー文字列が欠けていて、正しくコピペしきれていませんでした、というありがちな話。
本作業としては、間違い自体は検知・修正して正しく保管できれば良いので、 それでこの作業はおしまいなのですが、仕事に慣れてきたせいもあり、 普段、慎重な確認や注意が必要なはずの仕事を少し適当に済ませてしまう傾向があるので、 この後、彼になぜミスったかなどを考えてもらいました。
そうしたら、だいたい以下のような考察と、相談を頂きました。
【質問】
1. チェックの観点
2日に分けて（次の日にもう一度）見直しチェックをしたのに、それでも間違えてしまった。 これはチェックするべき観点を誤っているからではないか？ どんなことに気をつけたら良いのでしょうか？
2. チェック方法
漏れなく誤りを検出できるような良いチェック方法はないでしょうか？
3. 意識の問題
そもそもチェックに対する意識が低いのではという認識がある。 どうしたらもっと意識を高められるでしょうか？
自分の胸に手を当ててしばし考え、そしてだいたい以下のような回答をしました。
【回答】
1. 仮説を立てていない
2回に分けてチェックをしても同じミス（見過ごし）をしてしまったのは、 彼が見直しチェックをする前に、 「どんなミスをしてしまう可能性があるのか」を考えていなかった、 つまり仮説を立てていなかったことに起因しています。 エンジニアの仕事に準えて言えば、テストケースを考えていないとも言えます。
どんなミスが考えられるか、から考えてチェックする箇所を考えれば、 チェック観点ははっきりしますし、集中できます。
但し、新たな仮説を考えず、類似作業を経験すればするほど、 慣れてしまって「思い込み」が強くなり、チェックの観点が狭くなるので注意が必要ですね。
第三者にダブルチェックを行ってもらう理由もここにあります。
2. 機械的な確認方法を考える
- と併用して、これを考える必要があります。 いくら意識を持ってチェックをしても、人間の目でチェックする限りミスは避けられませんし、時間もかかり非効率です。
その点、機械的なチェックができれば、誤りなく効率的に出来ます。
もちろん、最終的に自分の目でも大丈夫かの念押しをする方が良いですが、便利なツールをうまく活用したいところです。
今回新人に行ってもらったのはキー文字列の保存ですから、正しく保存出来ているかを後からチェックするには、WinMerge などのdiff用ツールや、Excelのセル2つに文字列を貼り付けて関数でチェックするなどの方法が便利です。
【Excel関数の例】
=exact (A1,B1)
=if(A1=B1,"OK","NG")
=len(A1)
使い分けとしては、
・ファイルが完全に一致するかの比較 → diffツール
・ログなど、文字列が行ごとに一致するかの比較、桁数の確認 → Excel
こんな感じでしょうか。
言うまでもありませんが、チェック方法（特にExcel自作の場合はロジックなど）が正しいかどうかの検証は大前提なので怠らないこと。
機械的なチェックが難しいもの（例えば出ている画像やレイアウトなど）は目視だけが頼りになるので、横に並べるなどして差異が目に入りやすい、比較しやすい工夫をした上で、指差し確認するしかありません。
3. 間違えたらどんな影響があるのか（どれくらいヤバイのか）を考える
最後はこんな感じですが、でも大事です。
どんな作業でもそうですが、失敗したら、また誤りに気づかなかったら、その後どんなまずいことになってしまうかを考えれば、それだけ真剣にチェックするというものです。
ただこれは大失敗した or 大失敗しそうだった、という経験がないと本当の意味で学べないというのが欠点です。
裏を返すと、経験をすると身に染みて分かるようになります。
なので、失敗して障害を起こすのは決してオススメはしませんが、会社orチームがピンチにならない程度に、失敗はたくさんした方が良いです。
実力のある人は失敗どころか、挫折するほどの経験を持った人ばかりです。
大失敗を経験できるのは貴重なのです。
その代わり、同じ失敗は繰り返さないことが大事です。
大きな失敗をした場合は次はないので、ハイプレッシャーが掛かるようになり意識は最高に上がりますｗ
こんなところでしょうか。
何年も仕事をやっていれば当たり前の事ばかりですが、こうやって整理して教えたことを、後輩がまた後輩に教えてくれればいいなと思います。
