JAWS-UG 三都物語 2014 今しか役に立たない EC2入門 2014夏

606
-1

Published on

Presentation slides at http://santo2014.jaws-ug.jp/speaker/t_someda/

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
606
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 大企業からベンチャーの CTO
    未踏ソフトウェアをやったエンジニアです

    tksmd という id でツイッターや github
  • ヌーラボは今、三つプロダクトを出していて、一つ目がドローツールの Cacoo 、この C のロゴのツールです。先日全世界で 100 万ユーザを突破しました。

    次に B のロゴの Backlog 。この会場の方でいえば Redmine を使っている方が多いでしょうか。Backlog は Redmine のようなプロジェクト管理ツールでこちらは主に国内で今は約 20 万ユーザ、有料契約が 2000 社ほどです。

    そして最後が Typetalk 。こちらはビジネス向けのチャットツールです。今プレビューベータということで絶賛開発中です。ご興味ある方は是非ベータユーザとして登録していただけると嬉しいです。
    キータイプのタイプに話すのトークです。興味があるけれど見つけられなかったというかたは、私宛にツイートしてください。
  • 今日の話にも一部かかわるところがある
    ワンコインで読める電子書籍
    ヌーラボブログでも紹介中
  • リーンスタートアップの図でいうところの 「Build」 のゾーンはボトルネックになりやすい

    取捨選択については話さない
    http://www.slideshare.net/ikikko/backlogcacoo
  • 仕事内容
    エンジニア、デザイナ、マネージャ、アントレプレナー

    普段一緒に仕事しているプロジェクトのメンバー数
    5人以下
    10人以下
    50人以下
  • リーンスタートアップの図でいうところの 「Build」 のゾーンはボトルネックになりやすい

    取捨選択については話さない
    http://www.slideshare.net/ikikko/backlogcacoo
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • リーンスタートアップの図でいうところの 「Build」 のゾーンはボトルネックになりやすい

    取捨選択については話さない
    http://www.slideshare.net/ikikko/backlogcacoo
  • 問題そのものが不明瞭な場合に、その問題を仮説検証し、そこから学ぶループを回すということを方法論として定めた。

    その中ではいかに速くこのループを回すか、そしてそこから学びを得るかが重要。
    またその学びから方向転換 (ピボット) することも選択肢にいれて柔軟な方針決定をすることの大切さがとかれている。

    -----

    まず、サービス開発をするには究極的な「不確実性」と立ち向かわなければならないからです。
    サービスを開始する前、また開始してからしばらくの間は、「問題」も「解決策」もわからないわけです

    「問題」というのは「どこにマーケットがあるか」「誰がコアカスタマーになりうるのか」といった、ビジネスのコアで、
    まず最初にあなたの「問題」が適切かどうかを確かめなければいけない。
    と同時に、あなたのビジネスを実現する、ドライブするための具体的な解決策も模索しないといけない訳です。
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • アジェンダは四つ

    まず、最近のソフトウェア開発をとりまく大きなトレンドを俯瞰してみて、今日の話題の中心となる「試行錯誤」の重要性を再確認

    その次具体的な方法として、試行錯誤を進めるための内容として、コストをかけず「作る」ための工夫と、試行錯誤を進める中で
    安心して失敗できる「環境」の作り方、運用の仕方をみていく

    そして最後に本日のトークをまとめて終わりにする
  • ありがとうございました。ご質問や共有、ディスカッションなどありましたら是非よろしくお願いします。
  • 今日の話にも一部かかわるところがある
    ワンコインで読める電子書籍
    ヌーラボブログでも紹介中
  • JAWS-UG 三都物語 2014 今しか役に立たない EC2入門 2014夏

    1. 1. 今しか役に立たない EC2入門 2014夏 夏の JAWS-UG 三都物語 2014/07/05(土) https://www.flickr.com/photos/dno1967b/13973517707
    2. 2. 染田 貴志 SOMEDA Takashi @tksmd JAWS-UG 京都支部長 AWS歴6年 株式会社ヌーラボ
    3. 3. http://nulab-inc.com
    4. 4. http://tatsu-zine.com/books/genba10things
    5. 5. 好きな AWS サービス http://www.flickr.com/photos/getbutterfly/6317955134/ EC2
    6. 6. EC2起動したこと ありますか?
    7. 7. 本セッションの目標 • EC2を起動する最短経路を知る • 一歩進んだ内容のさわりを得る
    8. 8. マネージメントコンソール
    9. 9. 心の目でこう見る
    10. 10. 心の目エクステンション https://github.com/tksmd/management-console-for- beginner
    11. 11. こうなる
    12. 12. リージョン
    13. 13. インスタンス起動! 1
    14. 14. Amazon Machine Image (AMI) AMI は OS のイメージ インスタンス起動後は変更できない 以下から、好きなものを選択可能 • 自分で作成したもの • AWS が提供するもの • コミュニティで作成され公開されているもの • AWS Marketplace で提供されてるもの 2
    15. 15. インスタンスタイプ インスタンスタイプは利用できるCPUやメモリ、 ネットワークのリソースを定めたもの インスタンスを停止すれば後から変更可能 • 汎用 • メモリ重視 • CPU重視 • IO重視 などのインスタンスファミリーから、自分の用途 にあわせてインスタンスタイプを選ぶ お試し用途には t2.micro がおススメ 3
    16. 16. 確認画面 画面上部の warning は security group に関す るもの。後から変更可能なものなので、お試し用 途では気にせずゴー。 詳細は 15:00 からの宮澤さんのセッションで! 4
    17. 17. キーペアの生成 キーペアはリモートログインするために必要。 指定しなくても起動出来るが Amazon Linux はパスワードログインを許可していないので 永遠にログイン出来ない。 生成した秘密鍵は二度とダウンロードできな いので、ちゃんと保管すること 起動後に変更は出来ないが、Linux では authorized_keys を追加すれば OK 5
    18. 18. いよいよ起動! 6
    19. 19. 6クリックで起動完了
    20. 20. ここから一歩進んだ内容 http://www.flickr.com/photos/83633410@N07/7658268052/in/photostream/
    21. 21. インスタンス情報
    22. 22. インスタンスの状態 http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html • Stop は電源切る • Terminate はサーバを廃棄する Stop 時にはインスタンスタイプの変更 が出来る。Stop 後に再度 Start すると、 物理ホストが変わる
    23. 23. Stop/Terminateに関する設定 • Terminate Protection • 有効に設定すると Terminate できない • うっかり Terminate 防止用 • デフォルトは無効
    24. 24. • Shutdown Behavior • shutdown コマンド実行時の挙動 • デフォルトは Stop • Terminate Protection より優先 • 原則 Stop に指定して host 内から shutdown –h はしない運用が吉 Stop/Terminateに関する設定
    25. 25. インスタンスストレージ http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html • 揮発性のストレージ • インスタンスタイプ 毎に容量が異なる • 再起動時は保持、停 止時に消失
    26. 26. 仮想化方式 • PV と HVM • AMI 選択時に決定される • HVM 優勢が今ココ • インスタンスタイプによって選択可能 な仮想化方式に制限あり
    27. 27. 仮想化方式とインスタンスタイプ http://aws.amazon.com/amazon-linux-ami/instance-type-matrix/
    28. 28. Amazon Linux AMI http://aws.amazon.com/jp/amazon-linux-ami/ • yum ベースのパッケージ管理 • パッケージリポジトリを AWS が提供 • AWS 関連ツールを同梱 • セキュリティアップデートも迅速 • 全リージョン・アーキテクチャ・仮想化 方式で使える
    29. 29. T2 ファミリー http://aws.typepad.com/aws_japan/2014/07/low-cost-burstable-ec2-instances.html • バースト可能なインスタンスタイプ • VPC のみサポート • 仮想化方式は HVM のみサポート
    30. 30. Elastic Block Store • EC2 で利用出来るハードディスク • ネットワークドライブ • ルートデバイスでも利用される • 最大1TBまで • 同一AZ内のインスタンスであれば付け替 え可能
    31. 31. 3つのEBSのタイプ http://aws.amazon.com/ebs/details/
    32. 32. EBS 最適化インスタンス http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html • EBSとのI/O専用の 帯域を保証 • インスタンスタイプ 毎に異なる • 時間単位の料金が上 乗せ
    33. 33. EBS Snapshot • S3へ差分バックアップ • Snapshot 中は元 EBS の I/O 性能に影響 • Snapshot から即座に EBS 作成可能 • 別AZでの EBS 作成も可能 • リージョンをまたいだコピーも可能
    34. 34. http://www.flickr.com/photos/munaz/2498380666/ まとめ
    35. 35. 本セッションの目標 • EC2を起動する最短経路を知る • 一歩進んだ内容のさわりを得る
    36. 36. 参考資料 • AWS ビギナー向け資料 • http://www.slideshare.net/satoshi1977/aws-ec2-20111124 • 初心者向けクラウド勉強会EC2ハンズオン資料 • http://www.slideshare.net/youukkari/ss-35327922 • 実践(Deep Dive)コンピューティング編 • http://www.slideshare.net/KoichiroNishijima/deepdive
    37. 37. 昔の資料を見る時の注意点 • インスタンスストア • EC2サービス開始時のルートデバイス 方式 • S3からイメージを取得して起動 • ストップ出来なかった • 現状は EBS Backed 一択
    38. 38. 昔の資料を見る時の注意点 • インスタンスタイプ • 旧世代 (ほげ1.ほげほげ) を今から新規 で積極的に採用する理由はない • インスタンスファミリーやスペックを ベースに現行世代のものに読みかえる こと
    39. 39. 昔の資料を見る時の注意点 • EBSのタイプ • 以前は Magnetic (standard) が標準 • パフォーマンスデータには注意 • General Purpose (SSD) が出た現在、 Magnetic を積極的に選ぶ理由はない
    40. 40. 昔の資料を見る時の注意点 • EC2 クラシック • 非VPC環境 (フラットなネットワーク) • 新規アカウントでは利用不可 • 幾つか制約があった • セキュリティグループが後から変更 出来ない • 固定のプライベートIPが使えない
    41. 41. ご清聴ありがとうございました!
    42. 42. http://peatix.com/event/40528/view

    ×