opsworkを利用すると自動化する範囲が拡大できる デプロイ、定型作業 EC2インスタンス中でopsworkエージェントが起動している 定期的にopsworkとインスタンスが1分間隔程度でpollingしている chefはsoloかzero
web consoleからも実行可能
スタック全体を変更する場合の用途。 chef cookなどもこちら cliやsdkにもある。 通常はこちら
開発やデバッグ用。sudoがいる。
setup -> deploy -> configure -> undeploy -> shutdown
各ライフサイクルにビルトインでレシピが登録されている configureはstack中のリソースがsetup -> deployが実行されると 他の全てのレソースに対してもconfigureが実行される
configureに入れるRecipeが重要！！
NagiosとかZabbixにさせてたことが柔軟にできそう
秘密鍵とかはjsonデータから渡しましょう
Chefもそうですな(Data Bag) プライベートサブネットないでopsworkするにはNat必須
デプロイ用のレシピを作成する cronやライフサイクルイベントを利用する gitのhookをjenkinsなどに流すその後にopsworkコマンド
運用用のレシピを適用することで Heart BleedやBashに一撃で対応
インターネットにつながる必要があるが エージェントを利用できる(Ubuntuのみ)
確か既存のEC2をopsworkに追加できたな...
ガリバーインターナショナル 月島さん 社内システムのAWS化の行方にタイトル変更
2014年に社内システムをAWS化
- 既存: 単純移行 -> 部分最適化
- 新規: 最適化
VPCやAZは後から変更しづらい m3はAで起動できなくなっている AZはACがあるが各ゾーンで役割を決める AZは新陳代謝があることを想定しておく
VPC PeeringができるようになったがSecurity Groupまで認識できないので サブネットベースにしないといけない
VPCを分けるシーン
- VPC内のリソースの枯渇
- 課金を分けたい
- 複数リージョンを使用する
200個以上のSecurity Groupはパフォーマンスが保証できない NW AclはVPCを横断する際に重宝する
システム移行があって既存DCと接続するには必須 DCを経由せず拠点とAWSを結ぶ閉塞NWのDirect Connectもあるらしい
Windowsサーバを使っているならADと連携したい！ 諦めた！ 頻繁なリソースの変更に向いていない
EC2でSQL Serverを構築 RDS使ってない理由
- 冗長化できない(AZ間はできるけどね)
- タイムゾーンが設定できない
- ディスクを増やすときインスタンスを消さないといけない(RDSの宿命)
SQL ServerをData KeeperとDB Mirrorを混在で使用 Cloud Formationでは新規にElastic Nicは作成してData Keeperとか利用する デフォはStatus Checkなどに利用されて使えないので注意
クエリによってEBSのIOがネックになってくる IOPSを上げても小規模のスケールだと意味がない
- PowerShellの事例が少ない
- IISやSQL Serverの事例も少ない
- AD
- 高速なIOに耐えれそうにない
- エンジニアがGUIに慣れすぎている
混在してもOSSを利用したほうがいい
同じAWSアカウントだとPolictyの改ざんリスクがある
Sonic Garden倉貫さん 心はプログラマ、仕事は経営者
社内ベンチャーをMBOした際にAWSでインフラをしていたので SW資産の買取だけで済んだ。
- 顧問としてすべての工程に関わる
- 月額を定額にして開発と運用を続ける
- 働く時間ではなく成果を提供する
- 納期を死守する約束はしない
納期があるとバッファが積まれる ないことで正直な価格になる
システムの完成は目指していない 内製はエンジニアの見極めが困難
クライアントが増えるとリソースが割き辛くなってきて 完成がないとずっとみないといけないイメージがあるが協力会社や 発注者のシステム部門の教育などの増員はどうしている？
ビジョナリーカンパニー2を引用
SIがしたかったが既存のBig Sierとは勝負できないので 納品のない受託開発というルールで戦う
SW開発はモノづくりではなかった 再現性のない問題解決の仕事 コンサルこそ本質 顧客プログラマという職業
新規事業 <-> 問題解決 ハイリスク <-> ローリスク
起業家, CTO, OSS, 顧問
専業、兼業、成果主義など自分のスタンスでSGで働ける
鈴木商店 白石さん 仕事ではまだ使っていない
例: s3にアップされた画像のサムネイルを自動で作成する
- トリガ: S3 DynamoDB Kinesis CloudTail
- 画面から設定できるのはS3のみ
- 利用メモリは128-1024MB
- タイムアウト1-60秒
Node.jsで記述したコードで操作 -> Node.jsでターゲットのイベントに応じたバッチ処理が記述できる
npmとか普通のライブラリも使えるみたい amdとか使えるのかなー
用途
- 加工
- メタ
- 通知
リクエスト数 + メモリ * 実行時間
やすい。ちょっとしたジョブサーバ
西谷さん
内容は上のと被っている
例
- s3にアップされた画像のサムネイルを自動で作成する
- DynamoDBのバリデーションチェック
- CloudTrailの結果を解析して通知ができる
CloudTrailだけでなくアプリのログをs3に配置すれば 同じ構成で使える
従来は監視サーバを準備して対応していた コードに集中できる オートスケールで面倒をみてくれる
他の言語にも拡張予定 /tmpに対してread/writeできる それぞれが隔離されたコンテナ内で実行される
Amazon Linuxベースで必要なMW等を zipで固めてアップロードもできる(コツがいる) Node.jsが必要 ステートレスな状態で処理を記述する必要がある
AMIロールを作成するときは権限が二種類設定いる
- execution: s3やdynamoなどの書き込み
- invokation: lambdaの実行
バックエンドでDocker使ってないかこれ？？？
MySQL5.6互換のRDB ライバルはOrackeやSQL Server プレビュー版を使ってみて ストレージは10GBから64Tまで自動拡張(MySQLならでは)
AuroralはDB Subnetは最低3つ必要。
日本無理じゃない？
r3.8xlarge(32cpu, Memory244GB)で年間500万円なーりー フルマネージドとはいいつつ規模感わからん
RACは各ノードがアクティブなので接続先をかえればいい Auroraは昇格に120秒程度掛かる
お金で解決 -> 金の弾丸