Download to read offline
![インプットとアウトプット
[1] シェア(興味を持ったり感銘を受けたことを伝える)
[2] 一言コメントでシェア(10倍理解が高まる+思いを伝える)
[3] ブログを書く
(100倍理解が高まる+外からの評価、外のものさしを知る)
[4] 登壇や発表をする
(1,000倍理解が高まる+外からの評価、知人が一気に増える)
[5] 執筆、寄稿
(10,000倍理解が高まる+収入モチベーション)](https://image.slidesharecdn.com/20190223jawsdays2019-190221125643/85/AWS-58-320.jpg)
Uploaded byMitsuhiro Yamashita
AWSへのシステム移行に伴う クラウドマインドへの移行
JAWS DAYS 2019 OpenMicで登壇しました資料です。 AWSへのシステム移行に伴う クラウドマインドへの移行 ~個人、組織のクラウドマインドへの移行によるメリットフル活用~
More Related Content
![[JAWS DAYS 2019 /Open Mic]AWSの運用最適化のためにNHN テコラスが提案していること](https://cdn.slidesharecdn.com/ss_thumbnails/jawsdays190223nhntechorus-190225070731-thumbnail.jpg?width=640&height=640&fit=bounds)
![[GOJAS] クラウドワークスタイルとSplunk](https://cdn.slidesharecdn.com/ss_thumbnails/gojassplunk20170728-170729063715-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to AWSへのシステム移行に伴う クラウドマインドへの移行
![[AWS初心者向けWebinar] AWSへのアプリケーション移行の考え方と実践](https://cdn.slidesharecdn.com/ss_thumbnails/20150915-awsmigration-150915091024-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
AWSへのシステム移行に伴う クラウドマインドへの移行
- 1.
- 2.
- 3. 自己紹介 ●山下 光洋 トレノケート株式会社 ラーニングサービス本部 テクニカルトレーニング第1部 技術教育エンジニア AWS認定インストラクター ●過去の経歴 ・SI ソフトウェアエンジニア ・ユーザー企業IT部門 ●コミュニティ ヤマムギ(勉強会) , JAWS-UG OSAKA, JAWS-UG IoT関西支部, kintone Cafe大阪, JP_Stripes Osaka/Tokyo, MasterCloud ●好きなAWSの サービス
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE
- 10. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory
- 11. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory 調達スピー ド 提供スピー ド コスト最適化 予測不可能
- 12. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory 調達スピー ド 提供スピー ド コスト最適化 予測不可能 必要な量を、必要なときに、 人の手を介さず調達して、 使った分だけ請求、 世界中のどこでも使える
- 13. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. 自己紹介も兼ねてクラウドと自分のなれそめを 開発方法の遷移 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory アジャイルソフトウェア開発宣言、SOA
- 22.
- 23.
- 24.
- 25.
- 26. Not CloudMind Load BalancerLBFail Over DNS Application DB Master DB StandBy
- 27. Not CloudMind Load BalancerLBFail Over DNS Application DB Master DB StandBy
- 28.
- 29.
- 30. Services, Not Servers 最低限OSは管理/運用するものOSの管理は任せて、 アプリケーション開発や、 サービス構築に注力
- 31.
- 32.
- 33.
- 34. Scalability, Disposable Resources 東京リージョン、m5.large 、Linux 13インスタンスを常時稼働 している場合 $0.1216x 13インスタンス x 24時間 x 31日 = $1,199.328 ($1=110円) 131,926円
- 35.
- 36. Scalability, Disposable Resources,Cost Optimize 東京リージョン、m5.large、Linux 必要な分をリザーブドインス タンスで計算すると 8インスタンス分 1年利用の前払い $ 482.112 ($1=110円) 53,032円
- 37. Scalability, Disposable Resources,Cost Optimize ・要らないときにも稼働。 ・足りなくなったら 手動で増やす。 ・定価で使う。 ・要る量だけを稼働。 ・足りなくなったら 自動で増やす。 ・割引で使う。
- 38. Scalability, Disposable Resources,Cost Optimize ・サーバーは 動かし続ける ・サーバーなどのリソースは 使い捨てする
- 39.
- 40. Managing Increasing Volumesof Data
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47. Architecting for Cloud LooseCoupling コンポーネントを疎結合にする Removing Single Points of Failure 単一障害点を排除する Scalability スケーラビリティを確保す る Automation 自動化して信頼性を高める Services, Not Servers サーバーではなく、サービスで設計 Optimize for Cost コストの最適化 Disposable Resources リソースを使い捨てする Databases 適切なデータベースを選択する Managing Increasing Volumes of Data 増え続けるデータを中心で管理 Caching キャッシュを使う Security すべてのレイヤーにセキュリティ
- 48.
- 49.
- 50.
- 51.
- 52.
- 53. 同じ仕事を繰り返す場合(クラウド以前) 速い 調達は遅い(ボトルネック) Traditional serverGeneric database Tape storage Client やったことがあるけど結果がわかっているか ら
- 54.
- 55.
- 56.
- 57.
- 58. インプットとアウトプット [1] シェア(興味を持ったり感銘を受けたことを伝える) [2] 一言コメントでシェア(10倍理解が高まる+思いを伝える) [3]ブログを書く (100倍理解が高まる+外からの評価、外のものさしを知る) [4] 登壇や発表をする (1,000倍理解が高まる+外からの評価、知人が一気に増える) [5] 執筆、寄稿 (10,000倍理解が高まる+収入モチベーション)
- 59.
- 60. 危機感も一つの気づきであり原動力 危機感トリガー マネージャ期 エンジニア期 現在エンジニア期 経験やらなければ確実に価値は下がる 一定を保つことはできない
- 61. 自己紹介も兼ねてクラウドと自分のなれそめを 25年間 20201995 2000 20052010 2015 Amazon.com Google検索 Wikipedia Skype Facebook YouTub e Twitte r Instagram SlackLINE Client Mobile client Smart Phone FireTVEcho Sensor Action CarHouse Bicycle Door lock Factory
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
Editor's Notes
- #3 RFPはこれ
- #10 1995年amazon.com, 1998年Google検索、2001年Wikipedia, 2003年Skype、2004年Facebook, 2005年YouTube, 2006年Twitter, 2010年Instagram, 2011年LINE, 2014年Slack、他には1996年にYahoo検索、2006年にUstreamなど
- #11 1999年Docomoさんのiモード、2007年iPhone、 ユーザーがコンテンツを作ってビジネスが成り立つ、多くのアクセスを可能とした、 提供するためにはハードウェアを調達していては追いつかない
- #12 具体的なエンジニアリングにおける課題とメリットのお話がありましたが、ビジネスの課題は？ スピードを早めなければならない、利用量が大きく変動するのでインフラも無駄なく変動させたい、ユーザーの口コミなどにより爆発するのでいつビジネスが急成長するか予測がつかないので固定で持てない、インターネット回線の進化によりユーザーに提供するスピード(パフォーマンス)で売上に差が出るようになったのでユーザーに近い場所に構築 ハードウェアからソフトウェアへ、所有から利用へ
- #13 インターネットの普及、マルチデバイス化、により生まれた課題に対して、解決しているのがクラウドコンピューティング
- #14 2006年にAWS誕生
- #15 AWSの6つの強みとメリットもその課題解決によるメリット
- #18 2006年1つから
- #19 2014年のJAWS DAYS のTシャツバックプリントの全サービス
- #22 2001年にアジャイルソフトウェア開発宣言 2004年頃からサービス指向アーキテクチャ ウォーターフォールでは仕様確定後の追加ニーズをブロックしていたため、開発結果が時代のニーズに追いつかない課題があったが、決めごとよりも柔軟性を重んじる開発方法への変遷により追加ニーズを受け入れることが可能になり、それによるビジネスの拡大が始まった。 Amazonもお客様の要望を聞きながら様々なサービス拡大を続けている。 AWS自身も95%以上は顧客ニーズとありましたがそれを受け取りながら拡大している。
- #23 なので増え続けるし今でも増え続けている。
- #26 これだけのサービスがあるのに、一つのサービスしか使わないのはメリットを活かしきれないかも。
- #27 まずはリフトとして持っていくだけでもいい。
- #29 OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- #30 OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- #31 OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- #32 EC2インスタンス、こんなに常時稼働？ オンプレミスでは常時稼働があたりまえ。
- #33 スケーラビリイティを確保し、かつ、リソースを使い捨てに
- #34 先程は1/5になった例ですが、この例ではわりと多いインスタンスが必要な6割ぐらいは使う例です。 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。 オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- #35 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。 オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- #36 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。 オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- #37 さらに割引ができます。このオプションがあることはもちろん隠してもなければ使い始めるときに基本的には説明もありません。 最低2台のサーバーが必要なシステム。6時には6台必要、9時には10台必要、12時には13台、15時には15台、18時には10台21時には4台、23時には2台。 オンプレミスだと13台常時起動。AWSだと必要なときに必要な数だけ。
- #38 OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- #39 OSのメンテナンス、可用性の確保、バックアップ、復旧が不要になる、任せる
- #40 画像も全部EC2を使ったwebサーバーから配信している
- #41 画像や静的なファイルはS3から配信 ECなどコンピューティングリソースでは計算処理だけを行い、使い捨てにする
- #42 データベースは何がなんでもRDBMS
- #43 NoSQL, データウェアハウス、キャッシング、適したデータベースサービスを使い分ける
- #44 CloudFrontでキャッシュを持つ
- #45 非同期でいい処理はLambdaにまかせる EC2とLambdaはSQSで疎結合しお互いが影響を受けにくくする
- #48 最適化の継続のためにはどうするか？ 今日来られた方々はいろいろ勉強されています。でもみなさんが全部対応するわけにはいきません。 チームメンバーみんなが変わる必要があります。ではどうしますか？ Architecting for Cloud読みましょう
- #49 Well-Architected Framework読みましょう それだけで人が動くわけがない。
- #51 なぜ、自律組織がいいか クラウドのメリットの一つはスピードです。 そのスピードを活かす組織かボトルネックになる組織か。 判断する人が少ないとボトルネックになります。
- #52 自分で考え自分で動く組織が必要になります。 統制よりも自立です。 何を移譲して何を統制するか、この判断は相手への思いやり。 これを移譲して責任をもたせるのは酷なのではないか、そういうものは統制対象にして承認とする。 それ以外は移譲する。
- #53 移譲して発生する失敗を歓迎する。 失敗のない組織に成功はない。 そもそもやらないと成功か失敗かなどは分からない。 人にやらされた失敗は人のせいにする、自分で判断した失敗は自らチャンレジする
- #54 昔はわかった。なぜなら経験者がいて、その経験したことと同じことをするから。なので経験者は承認者となり新たな実行者が経験者に指示を仰ぎながら実行する。実行者がそのうち承認者となり判断をする役割になる。世の中はそれでうまくまわっていたけどそれはもう破壊された。
- #55 今は「やってみないと分からない」をやる時代。 だからそもそも承認が意味をなしていない場合も多い。 意味をなさない承認のために、専門家でもない承認者に説明する、そのための資料作りに忙殺され、ビジネスへの貢献などまったくできない状態に陥る。 クラウドのメリットをまったく活かせていないといえる。
- #56 ちなみにもう一つのパターン。 やらなくていい。誰かが作るって指示を出せばできる。
- #57 チームに移譲して判断できるようにするためには、思いを伝え続けることも大切です。 理念やクレド、行動規範など、大枠のコンテンツもあったほうがいい。 そしてそれに対しての思いを伝える。伝え続ける。 そして黙ってやらない。何考えているか分からない人とは仕事はできない。 心の方向指示器 メンバーが安心して判断できる環境を作る。
- #58 判断するためには技術も知識も必要。 インプットは常に行う。 組織はチームメンバーのインプットを支援する。 大切なのはアウトプットありきでインプットすること。 そのアウトプットには外のものさしも使う。
- #59 外部に知人が増えてつながるとSNSに欲しいインプット情報が向こうから入ってくるようになる どの段階においても必ずリアクションをする。 否定しない。ダメ出ししない。アドバイスする。 じゃまをしない。マウントしない。 無反応は一番の悪。 外のフィルターをとおって社内に伝わると、勝手にエビデンス付きの評価になる。
- #60 35歳前後でなんとなく勉強しなくなりました。 やらなくなるとそれが当たり前になってしまって、ベンダーさんの言うことが正しい、経営層の判断がすべて、が当たり前と錯覚して考えない。 自社に特化したものしかやらない。新しい技術も学ばない。 新しい技術を使うことで今まで得てきた経験が無駄になるのでは。 ではなくて、今までの経験を本当に無駄にするか、価値あるものにするかは自分次第。 そのためには知るしかないし、学ぶしかない。 そうすることで今までの経験や知見が必ず生きてくる。 権限移譲も一つの危機感をもつきっかけになることはあるが、追い詰めないよう注意が必要。
- #61 35歳前後でなんとなく勉強しなくなりました。 やらなくなるとそれが当たり前になってしまって、ベンダーさんの言うことが正しい、経営層の判断がすべて、が当たり前と錯覚して考えない。 自社に特化したものしかやらない。新しい技術も学ばない。 新しい技術を使うことで今まで得てきた経験が無駄になるのでは。 ではなくて、今までの経験を本当に無駄にするか、価値あるものにするかは自分次第。 そのためには知るしかないし、学ぶしかない。 そうすることで今までの経験や知見が必ず生きてくる。 権限移譲も一つの危機感をもつきっかけになることはあるが、追い詰めないよう注意が必要。
- #62 1995年に戻れたら何をしますか？
- #63 私は本はあげる派です(入社祝いや誕生日祝い)。チームや組織が本一冊でよくなるなら安いものです。 自分が欲しい本も誕生日にもらえたりもするので結果OKだったりも。
- #64 良かれと思ってでも手とり足とり教えられると、自律は失われます。 気づきのためのインプットと、それを使える環境や権限、そしてアウトプットの環境を提供する。 必要に応じて人事制度でインセンティブ。
- #65 認定資格は提案や設計、構築、開発など仕事を任せていただくためのエビデンス。 たとえば今日私がしたお話が、認定資格を持っていない人が話していたら、「本当かな？」ってなる方もいらっしゃいます。 人事部門担当の方はどの資格がどれぐらいのことができるか、価値があるかぐらいは抑えておいたほうがいいです。
- #68 通算100日登壇、受講者数844名