#で仕事しがち。awsやazure | Explore Tumblr posts and blogs

tak4hir0 · 3 years ago

Link

2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。テクノロジーとテク��ックによる進化の流れテクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出てきても良さそうです。というわけで、講演では過去の流れを整理するとともに、現在のテクノロジーの状況を見つつ、次の言葉を探してみたいと思います（あくまでも私観なので、違うよ！という人は、ぜひ教えてください）。これまでの流れ Agile（2001年/テクニック）まずはアジャイルです。アジャイルはマネジメントテクニックにもかかわらず、ITの在り方を変えてしまいました。その仕組みを電車で喩えてみます。アジャイルは電車型定期的に電車を運行する上で重要なのは上の図の②と③の状態です。開発チームにとってみれば、②電車が出発し、到着するまでの間は安定した作業が可能です。出発した電車は乗降が許されないため、乗車中の客をちゃんと連れて行くことに集中できます。一方で、ビジネスチームにしてみれば③次の電車が発車するまでの間、誰を次の電車に載せるのか好きなだけ変えられます。ビジネスの状況に合わせて優先順位を変えるなり、仕様を詰めるなり好きにする。④次に電車が来る時に、きちんと決定していればいいのです。このようにアジャイルは「②開発作業を安定して行う」と「③ビジネスにおける変更を許容する」というのを定期的なタイムボックスという仕組みで実現しました。マネジメントの基本は「計画し実行する」ですが、そこを全く変えずに試行錯誤に向いた開発プロセスを実現しています。 Cloud（2006年/テクノロジー） Cloudは仮想化技術を土台にしながら、コンピューティングパワーのサービス化（XaaS）に成功しました。発電機を自家所有するのではなく、発電所の電気を従量課金で買ってくる。Cloud技術の発展によって、その対象となるコンピューティングパワーの形態は大きく進化しました。特にPaaSと呼ばれる領域では、ミドルウェアやインフラが複雑に絡み合うような機能であってもオンデマン��で購入できます。たとえばRDBであれば、ジオレプリケーションのような複雑な機能もボタン1つです。かつ、そのDBサービスの立ち上げは「ボタン1つ」だけではなく「コードの実行」でも得られます。インフラ構成がソフトウェア的に制御可能（Infrastructure as Code）ということは、インフラ構成の構築をパラメタを変えながら何度でも実行できたり、バージョン管理ができたりすることを意味します。これまでエンジニアは機能要件だけをコードを実現しました。クラウド上であれば非機能要件もコードで実現できます。その結果、エンジニアはクラウドによって機能要件も非機能要件も自由にコーディングできるようになったのです。 DevOps（2009年/テクニック）アジャイルの普及とともに、その対象はインフラや運用の��野にも及びます。2009年に行われたVelocity 2009における講演「10+ Deploys Per Day」では、開発担当者と運用担当者がツール（IsC、CI/CD、メトリクスなど）を共有し、文化（信頼、心理的安全性など）を変えていくことでアジャイルに協業できることをしめしました。 2011年にはNoOpsという言葉が登場します。刺激的な言葉ですが、その意味は「開発者が運用環境に手を入れるとき、ツールを使って自分でやればよく、運用担当者と話す必要がない」というものでした。Netfixのブログ「Ops, DevOps and PaaS (NoOps) at Netflix」では、これを「PaaSの整備」と呼んでいます。 NoOpsによってOpsはツールで行うことになった従来のやり方では開発者が作った成果物を運用担当者に引き渡していました。だから、運用担当者は、その受け入れに時間をかけてしました。しかし、DevOps/NoOpsでは、運用作業がすべてツール化/自動化されており、開発者は自らの手で運用環境に手を加えたり、成果物をデプロイすることができます。 Microservices（2014年/テクニック）アジャイルから始まり、DevOpsがもたらした恩恵をシステム構成として整理したのがMicroservicesです。サービス単位の独立性を担保するMicroservicesでは、サービス間の疎結合度を高めます。これによって個別サービスは、それぞれのタイミングでリリースすることができるようになります。それぞれのサービスを管理するアジャイルチームが自分のペースでサービスを改善できることが、巨大なシステム全体の改善速度をあげることにつながります。この前提がDevOps/NoOpeの発展です。運用作業のツール化や自動化がされていれば、サービスをどれだけ分割してもインフラ構成の管理コストは上がらないのです。つまり、Microservicesとは巨大システムでアジャイルを機能させる構造のことであり、その構造を支えたのがDevOps /NoOpsです。これからのための技術では、マイクロサービスに次に来るような言葉はなんでしょうか？その言葉を支えるテクノロジーがCloud Nativeであり、Serverlessであると考えています。 Cloud Native（2015年/テクノロジー） Cloud Nativeを推進するCloud Native Computing Foundationでは、Cloud Native Trail MapというCloud Nativeへの道のりを紹介しています。ここではオーケストレーション、サービスメッシュ、スト��ーミングについて説明します。 Cloud Native Trail Map オーケストレーション Cloud Nativeの中心がコンテナオーケストレーションツールKurbernetesであり、その土台がコンテナ技術です。コンテナは「アプリケーションと、その実行環境をパッケージできる」ことがメリットです。コンテナに入るなら、あらゆる言語・フレームワークが利用可能です。そのコンテナの実行を管理するのがコンテナオーケストレーションです。コンテナに対して以下のような機能を提供し、数千台・数万台といったコンテナであっても管理が可能になります。コンテナへのリソース割り当てスケーリング状態監視と復旧環境変数の管理サービスメッシュサービスメッシュは、サービス間の連携を管理するためのツールで、その代表がIstioです。サービス間の連携には以下のような横断的関心事があります。連携先サービスの検出とルーティング通信制御（認証認可、暗号化、流量制限など）障害対応（サーキットブレーカー、リトライ、障害注入など）通信状況のロギング特にセキュリティや障害対応のようなことを個別サービスが個別実装する無駄ですし、誰かがミスればシステム全体に影響を与えかねません。Microservicesは分割が主眼ですが、サービスメッシュは分割されたサービスを統合するための手法と言って良いでしょう。ストリーミング MicroserviceにおけるAPI連携と分散データ管理を進化させうるのが「イベント駆動」です。そもそも、同期API連携は密結合な手法です。元システムからすると相手のインターフェースを知っている必要があります。イベント駆動の場合、元システムはストリームに対してイベントを流すだけで、その先で誰が受け取って、何をするかを知る必要がありません。もちろん、同期APIは重要な手法ですが、イベント駆動にできる連携は多くあります。同期APIは密結合次に分散データ管理ですが、これもイベント駆動であればシンプルな解決ができます。元システムが配信したデータを先システムが都合よく切り取って自分のDBに保存しておけばいいのです。これはCQRSやEvent-Sourcingと呼ばれます。もちろん、全てのデータは対応できませんが、イベント駆動であればマスタもトランザクションも、それなりのユースケースで分散データ管理が可能です。イベントがデータ分散管理を簡単にするイベント駆動はリアルタイムでデータの状態を共有できます。基幹システム（SoR）のデータ変更をリアルタイムに外部連携できれば、基幹システムの機能をグッと減らせるようになります。イベント駆動を実現するためのデファクトスタンダードはApache Kafkaです。Kurbernetesにも最適化されてきており、今後、より注目されていくことでしょう。 Serverless（2015年/テクノロジー） ServerlessといえばFaaS Serverlessであり、その代表はAWS Lambdaです。ですが、メインで話したいのはコンテナを前提としたContainer Serverlessの進化系であるKubernetes Serverlessです。具体的にはGCPのCloud RunやAWS App Runner、標準仕様でいえばKnativeやKEDAです。これらのKubernetes Serverlessは、Kubernetesを前提にCI/CD・イベント起動・オートスケールの全てをプラットフォームとして提供しています。コードを書いてGitにいれておけば、そこから先のことが全て自動化されてしまうのです。NoOpsを、そのままプラットフォームにしたものといえるでしょう。これからいよいよ本題です。Cloud NativeやServerlessといった技術がもたらそうとしているものを整理しました。コンテナによってランタイムの言語やフレームワークの縛りがなくなったサービスメッシュによって分割されたサービスの統合を集中管理できるようにしたストリーミングによってAPI連携に変わる連携が可能になり、分散データ管理が簡単になった ServerlessによってNoOpsがプラットフォーム化されたただし、2021年現在、未成熟な部分があり、多くの企業は技術が成熟する数年後をターゲットにしたほうがよいです。現時点では、まず以下に取り組むことを強く推奨します（Kubernetesが余裕だよ、という組織は無視してください）。 Cloud Native Trail Mapにある1.コンテナ化と2.CI/CD イベント駆動については非同期処理で問題ない一部システムにおいてマネージドサービスのストリーミングを利用非KubernetesなContainer Serverless（AWS ECS Fargate、Azure AppSeriveなど）で動かすこれらのCloud NativeやServerlessを前提とした新しい言葉は「Event-First」のようなことだと思っています。ただ、もうちょっと要点を突いた言葉になるとは思います。リアクティブは難しすぎで、Data in Motionはイマイチかな...。さいごにテクノロジーとテクニックは、課題を解決するために進化をしています。この課題と解決方法を理解しておくと、それらの要素を採用する場合の土台がよくわかります。たとえば、Microservicesに取り組むならAgileとDevOpsは前提であり、ここに組織が慣れていないなら、実現は不可能です。逆に言えばAgileとDevOpsを実現していけば、自然にMicroservicesになっていきます。だって、それが歴史なのですから。こうした整理が皆様の役に立てばうれしいです。もし、もっと話を聞きたいとか、質問がある、とかがあれば、どうぞTwitter @yusuke_arclamp にメンションいただければと思います。

#arclamp

0 notes

daisukeh · 4 years ago

Photo

8月の課題図書 … (勝手に)時間がない！

クラウド開発は以前から興味があったし、前職ではNuxt.jsを少しだけ触っていたし、そもそもNode.jsやVue.jsは腰を据えて使ってみたかったところへ、仕事関係でサイト構築してみようかという機運が高まっているので、IPA-ES資格と並行して自主学習をしている。AWS（Lambda目当て）、Azure（Function目当て）にアカウントを作成して使い方を模索中、HerokuはすでにGitHubからデプロイしている。もちろん、ターゲットはNode.jsである。PHPでもよかったが、ローカルでApacheを立ち上げるのは面倒だと気付いた。PythonやGoはサーバー起動するからいいかも。JavaはやっぱりTomcatだよな～。

自分だけの勉強ならいいが、もしもの時に備えてウェブ開発初心者の学習コストを考えないといけない。とは言え、JavascriptやHTML5を覚えるだけでも大変なのに、HTTPのバックエンドとフロントエンドの仕組みをゼロから理解してもらうのは難しい気がする。開発に加わる意思を、自分で強く興味を持って開発力を身に着けるチカラに変えてほしい。

#vuejs #nodejs #aws #azure #heroku #web #server #client #programming

0 notes

owaspjapan · 7 years ago

Text

「OWASP Kansai x IoTSecJP ～今こそ語り合おうIoTセキュリティ～」に参加してきた。#owaspkansai #IoTSecJP

今回はOWASP KansaiとIoTSecJPの合同勉強会がOWASP Corporate SupporterであるPanasonic様で行われるということで、こちらに参加してきました。

筆者はたまたま帰省に合わせて参加できたのですが、とても楽しかったです。

本イベントページのURLはこちらです。

OWASP Kansaiのノベルティがイケてるノベルティでした。筆者ももちろんゲット！

(左:OWASP Top10 2017日本語冊子、右:OWASP Top10 2017クリアファイル、下:ステッカー)

当日は基調講演が4本、その後同時開催でBOFが3本とLTが3本行われました。筆者はLT3本を拝聴しました。

すでに当日行われた講演の中で資料がアップされているものもイベントページからたどれますので、詳しくは資料を確認いただくとして、拝聴した講演を紹介したいと思います。

OWASP Kansai チャプターリーダーのはせがわようすけ氏より、OWASPは

Open ：みんなの力で

Web ：ウェブで

Application ：できたもんの

Security ：セキュリティを

Project ：何とかする活動

と紹介され、特にここ関西の産業はIT関連よりも製造業が多い傾向にあるため、IoTをテーマにセキュリティトピックに関して合同開催で勉強できる場があるのは良いことと述べていました。

最初の基調講演

「IoTセキュリティって特別なの？（仮）」と題して、日本ネットワークセキュリティ協会 IoT Security WG リーダー／株式会社カスペルスキー松岡正人氏の発表でした。来る途中の飛行機上空から見た富士山はとても綺麗だったとのことでした。

IoTセキュリティについては何か特別に考えるものでもなく、大まかに2種類あって、それが管理出来るか、出来ないかであると松岡氏は言いました。

IoTのアーキテクチャおよびセキュリティはNIST SP800-183および160を参照するとして、セキュリティはあくまで品質指標の一つであるとし、JIS X25010 システム及びソフトウェア製品品質モデルに基づいてソフトウェアセキュリティと同等に対応してほしいと述べられていました。また、これを特に読むべく人は、会社が傾くか儲かるか、会社にとって何を重要視するかを決めないといけない人、そういった志ある人は特にきちんと読もうと述べられていました。

次に、JNSAの活動の中では、2015年頃からIoTの中でも特にコンシューマ向け機器(つまり管理できないIoT)に関するセキュリティを考えないといけないという話があり、2016年におよそ130ページにおよぶコンシューマ向けIoTセキュリティガイドを作成したのでぜひ読んで欲しいとのことでした。

さらに、Industrial Internet Consortium(IIC)の紹介では、IoTのセキュリティについて、企業同士が実際にお金を出し合って確認するプロジェクトが存在すること、また、ドイツのIndustrie 4.0のロシア版である4.0RUについての紹介を行われ、あらゆる国での検討が進む中、IoTが今後、「Internet of Threats」とならないよう対策していく必要があるとして、講演を締めくくられました。

二本目の基調講演

「組み込み屋から見たIoT機器のセキュリティ～小さな機器でも気になる大事なこと～」と題して、株式会社アットマークテクノ代表取締役實吉智裕氏の発表でした。

Armadillo-IoTというゲートウェイ製品を開発された實吉氏は、IoT製品における考えられる脅威(盗み見、なりすまし、改ざん、システム侵入、マルウェア実行、物理攻撃)とその対策方法について説明されていました。最近ではMicrosoft AzureやAWSのIoT Hubを活用することもリスクを軽減することの一つと紹介していたが、機器そのものに対する物理攻撃(UART接続、JTAG接続、ROM吸い出し)の対策を怠ってはいけないと實吉氏は述べていました。

開発者のために開けられているシリアルポートが結果的に脅威となることもあるとし、UART接続やJTAG接続の回避方法としてパスワード認証や物理的に閉じることも検討、またROM吸い出しにはセキュアブートで対策としていました。IoT機器の接続に閉域網(Intranet of Things)を使いたがるユーザーも多いがこれらのリスクも確認しながら、最終的に守りたいものとかけるコストとのバランスが重要と締めくくりました。

三本目の基調講演

「Webセキュリティ診断士からIoT診断にシフトしたときの課題」と題して、IoTSecJP代表　黒林檎氏が発表されました。全身、黒ずくめの男でした。

公開されている資料はありませんが、当日の講演では、IoTのセキュリティ診断は、そもそも診断項目が曖昧である現状、診断対象とするレイヤーが広すぎ、さらに情報の少なさを嘆いておられました。

診断項目が曖昧であることについては、Webでは例えばXSS、CSRF、SQLインジェクションの対策が出来ていれば良いとする診断レポートもあるが、IoT診断ではこの項目が不明瞭であるとし、だからといってOWASPにはIoT Top10というドキュメントもあるが、これに準拠できていれば問題なしなのかというと、これに完全準拠するなんて現実的に無理で、準拠できているから大丈夫なのかといえばそうではないと述べていました。(筆者もOWASP IoT Top10に完全準拠！と謳っている製品は見たことありません。)

レイヤーが広すぎる点については、IoTを中央に、関係する分野としてFirmware、Web、Protocol、Crypto、Hardware、Otherを表し、これらの領域をカバーし合える他のセキュリティ専門家と一緒に考えるべきと話されていました。IoTセキュリティ診断の診断価格も悩まれていました。あなたなら、1台のIoT機器の単価が1万円だとしたら、どれだけの診断費用をかけますか？回答は難しいですね。

最後に情報の少なさに関する点では、やはり日本語のサイトはまだまだ少なく、海外のサイトから、その中でも本当に自分が欲しい情報を入念に調べ上げて続けているということ、技術検証内容が正しいかどうかを社内勉強会等で知見を共有し、周りとともに成長していく中で、現在は本を執筆中であることを告知して、時間になったため無慈悲に途中で発表が打ち切られました。

最後の基調講演

「必要とされるPSIRTとなるために」と題して、パナソニック株式会社　製品セキュリティグローバル戦略室　中野学氏による発表でした。

Panasonic PSIRTのお話で、PSIRTの役割についてお話され、開発現場や関係者との良好な関係を築きながら、確実な情報・確固たるエビデンスを元にインシデントレスポンスを行っていると述べられていました。組織としてのPSIRTは脆弱性の質や、商品、サービス内容、開発現場の状況を踏まえた上で、修正に向けた最適解を求め続けることが必要なのはおそらくどこのPSIRTでも言えることなのかもしれません。脆弱性を見つけるのも、攻撃するのも、作ってしまうのも、修正するのも全て人なので、冷静に収束に向けた行動、そして原因の追求以上に再発させない仕組み作りが大事と中野氏は最後に大切なことを伝えていました。

今回は基調講演がIoT機器の

企画設計

開発

診断、攻撃

リリース後のインシデント対応

という、製品の企画者、開発者、運用者に向けて伝えたいことを存分にお話いただいた内容でした。

また、どの方も似たようなことをおっしゃられていましたが、OWASP KansaiやIoTSecJPといった場所が様々な人を繋ぐ場・コミュニティであり続けることを期待していると述べておられていました。筆者もいくつかのコミュニティのコアメンバーであるので、そういう場を今後も提供し続けれればと考えます。

LTの1本目

「法律とITが仲違いしないための問題意識｣と題して、弁護士　伊藤太一氏による発表でした。

過去に起きたユーザーVSベンダーの訴訟問題等を取り上げ、TechとLegalの人達の間で思考に大きなギャップが出来てしまっていることを注視しており、IoT時代にセキュリティの法的責任に耐えうるガイドラインが作られるのか？是非、TechとLegalの人達で手を取り合って作り上げよう！と話されていました。

LTの2本目

「組込み(IoT)機器開発者目線の情報セキュリティについて」と題して、イークラウド・コンピューティング代表 (情報処理安全確保支援士)　古都哲生氏による発表でした。

マジコンや監視するバービー人形を例に、もっとIoT機器を普通に扱おう、本来の機能・性能の範囲で楽しもう！電線繋がないでよ！と組込み機器開発者の苦悩が伺える生の声を聴くことができました。消費者目線からすると、脆弱性を露呈してしまった会社は一般的に人様からお金を貰って製品を供給しているため、脆弱性があるとは何事？と言われることは多々あります。特に安価な組込み機器においてセンシティブな情報を取り扱うことのリスクをよく考え、値段相応の使い方をして欲しいと多くの会社は考えているとのこと。だからこそ、開発・生産するIoT機器については、これまでの開発の仕方で本当に良いのか？あらためて見直してほしいと訴えかけていました。

最後のLT

「自動車に対するなりすまし��撃の脅威」と題して、広島市立大学　家平和輝氏による発表でした。

自動車のセキュリティの脅威分析を行い、防御機構の開発を考える必要があるとし、車載LANを題材に、自動車内部のコンピュータ(ECU)がCAN(Controller Area Network)で繋がっており、このCANがなりすまし攻撃に脆弱であると説明しました。なかでも検知の難しいなりすまし攻撃について研究している家平氏はバスオフ攻撃で正規の端末で攻撃が検知されることを無効化し、なりすましデータ送信を有効にさせる方法の検証結果について述べていました。最後に、OBD-IIポートに怪しいものが挿さっていないことを確認しましょう！として講演を締めくくりました。

およそ三時間近く、IoTのセキュリティについて学んだ非常に濃い時間でしたが、当日110名近くの参加者もおそらく学ぶものがたくさんあったのではないでしょうか。もちろんこれらを、学んで終わるだけでなく、周りに共有したり、これらをもとになんらか個々にアウトプットできるといいですね。

今後も今回だけに限らず、OWASP Japan ローカルチャプター主催の勉強会に参加して、こういったフィードバックをできる機会がありましたら、書き連ねてみたいと思います。

OWASP Japan PRチーム

吉江

1 note · View note

awsexchage · 5 years ago

Photo

動画配信プラットフォーム ~ AWS から GCP 二刀流への道のり ~ https://ift.tt/2mDmSdx

streampack の動画配信プラットフォームの開発を担当している Tana です。

概要

弊社は先日 Google Cloud

パートナー認定を取得しました。既存サービスは AWS をベースに提供してますが、今後GCP上で動画配信のニーズも増えてくることも考えられ、この機会に知見を増やすべく、streampack on GCPを試みました。その際のプロセスとトラブルシューティングなどを共有できればと思っております。

リソース部分の構成

リソース AWS GCP 仮想サーバ(コンテナ) ECS(EC2) GKE コンテナレジストリ ECR GCR データベース RDS(MySQL) CloudSQL ストレージ S3 GCS(Storage) CDN CloudFront Cloud CDN 動画変換 MediaConvert / ElasticTranscoder FFmpeg on GKE ログ CloudWatch Logs StackDriver

GCP には動画変換のマネージドサービスはないので、FFmpeg を使って HLS に変換させます。

アプリケーション部分

アプリケーションにて AWSへの操作は AWS Ruby SDK v3 を使用していたので、 Aws::というキーワードで影響範囲を洗い出し、動画コアである下記の部分の修正が必要でした。

アップロード

サムネイル

動画変換

配信

他のオプショナルな機能の一つとしてライブからアーカイブファイル対応にて S3 + SQS + Lambda を使ってもいましたが今回は割愛

アップロード

GCSは AWS S3 と同様に Direct Upload をサポートしておりましたので、下記のように put signed URL を返してくれるように API を修正しました。 GCP or AWS の環境に応じてそれぞれのURLを返し、アップロード時にセットしてます。

コマンド

$ gsutil signurl -m PUT -d 1d -c video/mp4 ~/credentials.json gs://your-bucket-name/test.mp4

put-signed-url.rb

storage = Google::Cloud::Storage.new bucket = storage.bucket(ENV['GCS_BUCKET']) sslkey = OpenSSL::PKey::RSA.new("-----BEGIN PRIVATE KEY-----\n...") put_url = bucket.signed_url( s3_key, method: 'PUT', signing_key: sslkey, issuer: ENV['GCS_SV_ACCOUNT'], expires: 1.hour, content_type: filetype # これ重要 )

signed URLのレスポンスが体感で数秒かかるので、signed URL のリストを取得したり、リクエストが多いサービスでの使用は注意が必要そうです。

サムネイル

CarrierWave, Fog のライブラリは様々な AWS, GCP, Azure など Cloud Provider をサポートしているので、基本設定を変え同じコードでサムネイルの生成・リサイズ・配信ができます。

動画変換

GCPは動画配信のマネージドサービスはないので、worker デーモンプロセスを GKE の pod 上で FFmpeg を使いバックグラウンドで変換させてます。もともとローカル開発で AWS リソース設定していなくても動くことを考慮していたので、フィーチャーフラグにて ElasticTranscoder -> FFmpeg 切り替えれるようにしてます。もちろん GKE の特徴でもあるスケーラビリティなので、Node or Pods 数を増やして並列で処理することも可能です。

Adaptive Bitrate対応や透かし入れたり、プリセット定義や複数パイプラインでの実施を考慮するケースではどうしても自前でやると workflow が大変なので、要件に応じてマネージドサービスを使う方が賢明でしょう。

GCPリソースセットアップ

GCS(Storage)

AWS S3と同じオブジェクトストレージで概念や操作も似ているので s3 経験者であればスムーズかと思います。GCPの便利なのが、 Cloud Shell 上から、簡単に操作できるところです。わざわざ AWS CLI のセットアップや AWS IAM からcredentials を発行しローカルにセットしたり、セットアップは不要です。

GCS の操作は gcloudではなくgsutilになります。

ヘルプ

$ gsutil help

コピーファイル

gsutl cp test.mp4 gs://your-bucket-name/

public対応

$ gsutil -D setacl public-read gs://your-bucket-name/test.mp4

cors 設定は画面上からできないので、下記のコマンドで実施します。

$ gsutil cors set cors.json gs://<your-bucket-name> ---- [ { "origin": ["https://<your domain>"], "responseHeader": ["*"], "method": ["GET", "PUT", "HEAD"], "maxAgeSeconds": 3600 } ] ----

クレデンシャルの発行

AWS の場合は IAM から発行しますが、GCSの場合は Storage -> Settings から発行できます。

CloudSQL – データーベース

GKEからデータベース接続する際は下記の方法があります。

public IP

cloudSQL Proxy

public IP だと変わってしまうことがあるため、セキュアな接続である Proxy を使った方法で実施しました。

サービスアカウント

クレデンシャルの発行

Owner 権限を持ったアカウントで Cloud SQL Client の Role を持ったサービスアカウントを作成します。 credentials を上記のように取得して、後ほど使うのでダウンロードしておきます。

注意: Owner 権限出ないと、Roleの選択画面が出てこないので注意です。

GCR – コンテナレジストリ

ECRと違って、リポジトリの事前作成は不要です。 GCRに push できるように下記のセットアップして、ホスト先を指定して push します。

$ gcloud auth configure-docker

GCRホストが一番近そうな asia.gcr.ioを指定してます。

$ docker build -t asia.gcr.io/<your-project-name>/<image name> . $ docker push asia.gcr.io/<your-project-name>/<image_name>

Vulnerability scanning(beta)

コンテナ内の脆弱性診断がベータ版ですが、提供されております。 Enable にするだけで、push後に診断してくれます。

下記はアプリケーションの結果です。 https://qiita.com/ytanaka3/items/8c308db2ee58ea63626a にてブログ書きましたが、コンテナイメージの最適化を行っていたので、大丈夫でした。

nginx だと、、、

見直しが必要そうです。。

ミドルウェア周りのセキュリティ対策を DevOps標準フローとして導入できそうです。

GKE – Google Kubernetes Engine

cloudsql-proxy 設定

先ほどのサービスアカウントで設定しダウンロードした credentials.json を下記のコマンドにて Secrets として登録します。

$ kubectl create secret generic cloudsql-instance-credentials \ –from-file=credentials.json=/path/to/credentials.json

Cloud Shell の場合は credentials のアップロードは下記の方法で可能です。

確認は下記のコマンドでも確認できます。

$ kubectl get secrets

ConfigMap 設定

環境変数を deployment or pod ファイルにそれぞれ定義することもできますが、すでに準備した .envファイルを読み込ませて、登録します。

$ kubectl create configmap cms-config –from-env-file=.env

DB_HOST=127.0.0.1 DB_USERNAME=xxxx DB_PASSWORD=xxxx DB_NAME=xxxx GCS_BUCKET=bucket-name GCS_KEY=xxx GCS_SV_ACCOUNT=xxx

cloudsql-proxy のケースのホスト名は 127.0.0.1 になりますので注意が必要です。(public IPではないです。)

正しく登録されたか、中身の確認は下記を実行します。

$ kubectl get configmap app-config -o yaml

deployment 設定

$ kubectl create -f app-deployment.yaml

app-deployment.yaml

#... 抜粋 # cloudSQL用のイメージ containers: # CMSアプリ - image: asia.gcr.io/<your-project-name>/<repository> name: app 　　　　　　# configMap で定義した環境変数読み込み envFrom: - configMapRef: name: cms-config # ... 抜粋 # cloudsql-proxy サイドカー - image: b.gcr.io/cloudsql-docker/gce-proxy:1.14 name: cloudsql-proxy command: ["/cloud_sql_proxy", "-instances=<your-project-name>:<db-region>:<db-name>=tcp:3306", "-credential_file=/secrets/cloudsql/credentials.json"] securityContext: runAsUser: 2 allowPrivilegeEscalation: false # マウント volumes: - name: cloudsql-instance-credentials secret: secretName: cloudsql-instance-credentials

細かな設定で時間を要したのが、volumes マウントです。上記のコードには記載してませんが、ECSだとマウントする際は、マウント元の情報はキープされますが、k8s だとマウントしたパスのファイルは削除されます。nginx 上で assets を配信していたのですが、アクセスできなかったので、

$ kubectl exec -it <pod name> -c <container name> sh # <- nginx

にて確認すると、コンテナ内で assets 配下を見てみると空っぽでした。調べたりテストする限りだと仕様のようなので、lifecycle:postStart にてコピーするように対応しました。

サービス設定

サービス(Ingress)はロードバランサーであり AWS でいう ELB(ALB) に当たります。

$ kubectl create -f app-service.yaml

app-service.yaml

apiVersion: v1 kind: Service metadata: name: app-lb labels: app: app spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: app: app

確認は

$ kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE app-lb LoadBalancer 10.4.15.244 xx.xxx.xx.xxx 80:31485/TCP 18d

払い出された EXTERNAL-IP にアクセスしてサービス確認します。

DB接続がうまくいかない場合は？

StackDriverを確認します。

またはコマンドからもログを確認できます。

$ kubectl get pods # pod名を取得 $ kubectl logs -f <pod name> <container name> # cloudsql-proxy

pods&service の削除

$ kubectl delete -f app-deployment.yaml $ kubectl delete -f app-lb.yaml

Cloud CDN

今回は静的ファイルのHLS動画ファイルは GCS に置いてますので、Cloud CDNで配信できるようにします。Cloud CDN は Load Balancing(Backend & Frontend)の組み合わせ設定が必要のようです。

バックエンド設定

Storageがオリジンになりますので、backend には Storage を指定します。

フロントエンド設定

設定すると、フロントエンドのIPアドレスが発行されます。

パスルール

パスルールは今回は特にルーティング不要なので、デフォルトのままにしてます。

下記は生成後の画面になります。

とりあえず、IPアドレスが払い出されたので、そのIPと bucket にある public ファイルにアクセスできます。キャッシュのインバリデーションは AWS CloudFront に比べると数分かかりますので、サービスによっては注意が必要です。また、Cloud Interconnect を使えば、Akamai や Fastlyでも配信できそうなので、マルチCDNで配信するニーズがある場合は最適かもしれません。 https://cloud.google.com/interconnect/docs/how-to/cdn-interconnect

結論

あくまで私がGCSのメリットを実感したことは、

プロジェクト間のスイッチが簡単(dev -> production, project A -> project B)

Cloud Shell にて、疎通確認やコマンドにて動作確認が可能

デベロッパーフレンドリーな管理画面(選択肢が最低限)

AWS に比べると Role に悩まされることが少ない。

まだ理解できていないリソースやアプリ側で対応できていないところ��あり課題が山積みですが、パブリッククラウドの知識・経験があれば GCPリソースのセットアップはスムーズに進めることができました。アプリ側も改善し、個々のリソースの最適化を行い、スムーズにGCP上で構築&サービス提供できるように進めればと思います。

元記事はこちら

「動画配信プラットフォーム ~ AWS から GCP 二刀流への道のり ~」

September 25, 2019 at 04:00PM

#AWS #Official #Blog

0 notes

yaasita · 6 years ago

Text

■求人に書いてあることと違うことをさせる株式会社アイビス

株式会社アイビスは、お絵描きアプリのアイビスペイント出しています。

私は、株式会社アイビスで2年ほど働いていましたが、精神的肉体的に社会復帰できなくなってしまったので退職しました。

理由は2つあります。

1つ目は、営業の人が案件とエンジニアの技術力を考えないで、プロジェクトに任命させることです。

私は、言語としては、C++を基本的に触っていましたが、営業の方から案件がないからGo言語でもいい？というか、それしかないからお願い、と頼まれました。案件は水ものだししょうがないよねと、営業の方自信が自分にいいきかけせている感じでした。それでプロジェクトに入りましたが、現場ではめちゃくちゃ怒られる毎日でした。そもそものお作法（変数の型宣言が後置である）も知らないからです。

このことでプロジェクトに合っていないと営業の人に言って離任を申し出ますが、うちではみんなこんな感じだから我慢してと言われるだけでした。そのまま、3ヶ月が過ぎたら10キロ以上も痩せて、配属先の会社から離任を申し出てきました。

離任後は、自社に戻ると営業の人は、顔も合わせず次のプロジェクト先をメールで伝えるだけでした。

もちろん次も経験のないJavaとAWSの環境でインフラ設計、製造です。しかも、プロジェクト先が都内から1時間30分以上もある厚木です。対応できなくものすごく怒られ1ヶ月でお客さんから離任を告げられました。

このことで、求人に書いてあることは自分の得意な言語で仕事出来るはずじゃないですかと営業の方（採用も担当していた）に問い詰めますが、仕方ないじゃん、案件は水ものなんだしと。そんなことなら、もっと遠方に行かせるか炎上案件に行かせるよと言われました。その後も、同じような案件で数か月で終了する感じで2年続けて精神的肉体的にまいりました。

2つ目は、1つ目と似ていますが、求人内容と書いてあることが全く違います。

私は、C++でモバイルのアプリが少しつくれる程度で会社の人とチームを組んで、開発がしたいがためにこの会社に入りました。

しかし、求人内容に書いてあることとはほとんどが違います。

求人に研修では、あなたに合わせた研修とありますが、基本は放置です。

ワードのドキュメントにテトリスをつくってください。仕様は○○ですとA4の1ページにも満たない、仕様書があるだけです。更新日も5年以上前になっています。

基本誰とも話さずググって下さいと。質問してもググって下さいと言われるだけです。Redmineを使って質問ができますが、一日一回だけです。しかも、研修用で使えるPCはメモリは2GBで、2つ以上アプリを開いたら、フリーズします。

研修は、4ステップありますが、ほとんどの人がステップ1も��わらないで、現場に行くことになります。

現場に行く時は、もちろん営業としての単価がいい案件��ので、炎上か高難易度の案件です。未経験の人でも大丈夫で4割が未経験でチームでプロジェクトに入りますと求人表に書いてありますが、一人で案件に行かされます。チームで行くことはたまにありますが、みな個人プレーで自社の人とは関わりません。フォローもなく、むしろ出来なかった時だけに怒鳴られます。平成終りなのに、やっていることは昭和初期の根性論のような会社です。

最後に、会社のトップの人は自社開発のアプリしかしていなく、全く経営をしていません。

例えばですが、今だに、派遣先での勤怠を自社に提出する際は紙ですし、社内システムは10年以上前のものを使用しています。

社長はめんどくさい事は、管理職に丸投げをして、暇さえあればツイッターをしているような人です。そんな暇があるならば、社内インフラを少しでも良くしてほしいですが、それも気づいてないです。

さらに、今後上場を考えています。上場したら優秀な人材が集まり、今いる人と競わせて、優秀な人だけ残すと言っているのです。社員をただのお金としてしか、考えていないので非常に残念な経営者です。

ちなみに私は、中途で入り手取り20万円で入社しました。しかも一年目はボーナスなし。年収300万円も行かなかったです。しかし、今転職した会社では、月給は32万で、手取りは28万円になりました。やっている事は変わっていないのにです。年収も400万円までいきました。これでも、他の会社と比べたら少ない方ですが、株式会社アイビスがいかに低賃金で働かせていることか身に染みました。

エンジニアを安く買い叩かれることがないように、間違えて自分と同じようなミスをして欲しくないために今回記事を書きました。

少しでも多くのエンジニアが豊かになるために。

※色々とコメントありがとうございます。

少しだけ、追記します。

今回の記事は株式会社アイビスが都合のいい人だけ集めていること、SES（システムエンジニアサービス。エンジニアの派遣です。）に問題があることをもう少し説明します。

株式会社アイビスは、都合のいいエンジニアだけ集めて、後は切り捨てるという考えです。プロジェクトにマッチしない人でも、辛抱強く続けられる人は会社としては利益になる。優秀でなんでもできる人ならマッチしなくてもどのプロジェクトでも活躍できる人が残っている人の2パターン。仮にマッチしなくてもやめる人のケースの場合でも、責任は営業とエンジニアになりますが、実質エンジニア（話し合っても、普段話しなれていなエンジニアは、丸め込まれる。または、受け流されて、変わらないことに気付いてやめる）になる。会社としての損害はほぼなく、利益は減るが、新たなプロジェクトを探し出せることになっている。常に求人をしているので、そんなことを知らない人が同じようなループに入ります。そこで、続けられる人が見つかれば会社としてはラッキーという感じです。そして、そこに残っている人はすごい低賃金で歯を食いしばってやっている人��、ものすごい技術力がある優秀な人かの両極端になります。自分がどちらか気付いたときは、そのポジションの言動をとるようになっています。歯を食いしばるか、サクサクコードモンキーになるか。

常に求人が出されています。

https://tenshoku.mynavi.jp/jobinfo-214515-2-3-1/?ty=kyujin&src=ssS

もう一つ、SESの問題点は上記であるように派遣でプロジェクトに入るところです。チームで何かしらをつくりますが、この時に株式会社アイビスの営業、会社、エンジニア、お客さん（1次受け、2次受けで責任者が複数にいる状態）いますが、そもそもプロジェクト自体が炎上していて、失敗したら責任はお客にあり、エンジニアは地獄をみます。営業と会社は「しかたないでしょ」となります。もちろん、成功したら「よかったよかった」になります。ほとんどの場合は、微妙に燃えています。そこでカギになっているのがエンジニアの力量ですが、プロジェクトによって使う技術が決まっていないので、地頭力か歯を食いしばる力（お客は求めていないが、自社は求めている。派遣するだけで利益になるのだから）が求められる。結果的に優秀な人は、機械学習（Python）であったり、Reactであったり、クラウドの（AWS、AZURE、Google Cloud Platform）にも対応できます。お客さんもエンジニア便りになって、正しくプロジェクトが成功できるかは、優秀な人を揃えられるかどうかです。歯を食いしばったところで意味がないのに、会社というポジションでそれをやらせる会社はどうかなと思います。しかし、会社も利益を出さないいけないということで、目先のお金（SES）で稼ぐのです。

少しでも、エンジニアいい方向に進めればいいと思うので、コメントが増えましたら、新たな問題点を提起します。

https://anond.hatelabo.jp/20181211072336

#増田

0 notes

oom-killer · 5 years ago

Text

2019/12/09-22

*アマゾンで「サクラレビュー」投稿が横行　チェックサイト開発者が語る意外な正体は… https://www.itmedia.co.jp/business/articles/1912/11/news121.html >「思いのほか日本人が多い。学生や主婦も多く見受けられ、気軽に参加 >できる仕事として考えられているのかもしれない。参加者の中には、 >やらせレビューの投稿を『簡単な副業』などと情報商材化することで >さらに稼ぎを得ようと考える人もいる。そういう人が新たなグループを >作り、ねずみ講のように派生していっているようだ」

*EKSは本当にECSより難しいのか？ https://dev.classmethod.jp/cloud/aws/ecs-and-eks/ >「できることはEKSのほうが多い。けど、そのぶん習得がECSより難しい」

>ECSクラスター自体にはお金かかりません。無料です。対して、EKSは、 >0.20USD/時間。1ヶ月で144USD。

>kubernetesは普通に既存機能に影響があるアップデートが行われます。 >さらに、大雑把に言えば、同一のバージョンを1年以上使うとサポート >が切れます。

>ECSサービスは、実際にコンテナをクラスター上で管理?展開するために >ほぼ必須の機能なんですが、このECSのサービス定義パラメータが、往年 >の機能拡充に伴いめちゃくちゃ増えています。

>ぶっちゃけ「どっちもそれなりに大変」というのが率直な感想です。

*なぜ25年間無視していたIPv6に本気なのか？ https://www.kosho.org/blog/net/ipv6/why-now/ >アクセス網のIPv6化が進んできた。2019年の時点で、米国で5割、国内でも >2～3割程度のリクエストがIPv6になっています。つまり、IPv6対応のサーバ >を立てると、国内でも2～3割は既にIPv6です。この時点で、「ちょっと >本気で考えなきゃ」という気になってきました。

>速度調査の結果としては、以下のようなものとなり： > > - 夜間：IPv6 > IPv4 > - 昼間：IPv4 > IPv6

>日本のア��セス網IPv6普及率(良いデータが無いのでAkamaiのアクセスに対 >するIPv6率で代用）は、まだ2~3割ですが、米国ではすでに5割程度となって >います。

*IPv4には未来がない https://it.srad.jp/story/19/12/18/1620204/

*昔の自分に教えたいLambdaのデバッグ方法 https://speakerdeck.com/tomoki10/xi-falsezi-fen-nijiao-etailambdafalsedebatugufang-fa

*クラウド上のデータを完全削除したくても、ストレージの物理破壊は不可能……どうする？　AWSの説明は https://www.publickey1.jp/blog/19/_aws.html >ユーザーの責任においてストレージに記録されるデータをあらかじめ >暗号化しておき、削除時に暗号鍵も消去してしまう。 > >　これによりストレージが別のユーザーに再割り当てされたとしても、 >それ以前に保存されていたデータを読み取ることは不可能だ、という >わけです。

>AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSの >セキュアゾーンを離れる前に物理的に破壊されます。

*Lambdaの内部アーキテクチャ教えます！A serverless journey: AWS Lambda under the hood #SVS405 #reinvent https://dev.classmethod.jp/cloud/aws/reinvent2019-svs405/

*「AWS」「Azure」「GCP」で相次ぐ障害　クラウドを信じ切ってよいのか https://techtarget.itmedia.co.jp/tt/news/1912/20/news05.html

*教員用PC貸与が発端となった中学生による校内不正アクセス事案についてまとめてみた https://piyolog.hatenadiary.jp/entry/2019/12/21/045132

*MuZeroの衝撃。囲碁のルールを自ら学習しAlphaZeroを凌駕。 https://ai-scholar.tech/treatise/muzero-ai-355/

*CloudWatch Logs/統合CloudWatchエージェントの違いと移行時の注意点 http://blog.serverworks.co.jp/tech/2019/12/20/cloudwatch_agent_migration/ >実は CloudWatch Logs にログを送るエージェントは以下の2種類が存在します。 > > - CloudWatch Logs エージェント > - 統合 CloudWatch エージェント > >統合 CloudWatch エージェントの方が新しいエージェントとなります。 >統合 CloudWatch エージェントを使用すると、ログファイルだけではなく >カスタムメトリクスをCloudWatch Logs に送信できます。

>CloudWatch Logs エージェントと統合 CloudWatch エージェントでは >パラメータの指定方法にちょっとした変更点があります。

0 notes

miusukeeee · 7 years ago

Text

Devsummit2018

過去ログ

Dev Summit運用 8+8 * N列 16列ぐらい？ B 見える範囲だけで1部屋に5人ぐらいいる受付、音響、途中参加者の誘導*2ぐらい

撮影OKなのかNGなのかを表示する立て札みたいのあるといい

ランチセッションはガンガン入って食べさせて、食べてから聞く方がいい、音もあるし

参加者webアンケートに答えると、資料がもらえるってやりやすくない？？

運用について無停止でtokyo regionに持ってくる方法考えるデータとキャッシュがつらそうなのでslaveをtokyoにおいて、切替時と同時にマスターに昇格、ただ台湾もマスター気分いや、死ぬな、無理だ Scaleユニット、podの単位を正確にして、scaleさせる計画を練る今回のタイミングで、Nodeをscalableにしなくちゃいけないそして、その後にk8sでservice-deploymentでscalableに sakura-deploymentも nginxもかなりあ環境ちゃんと作りたい

memcachedを2こ使ってるけど、死んだら死ぬので、なんらかのなにかに移行する

そのうち、東京大阪両方に散らしたいよね

とりあえずSRE本配ろうか

B2 全アーキテクトとマイクロソフトの NoOpsのやつ

運用は設計をみすえて、、みたいな話

好きなものを好きな時にローンチしたい vs 一旦動いたシステムは変更したくない SRE本

開発と運用をわけるとか、そういうの、えぐいいまのMDUは運用と開発を同時にやってる→DevOpsだよね

いや、NoOps

Ops　10年戦争

運用保守はITILのリファレンスにもあるとおりレビューとかアホみたいにあるリードタイム長い、物理的限界→PDCAがふぁっきん長期

「変更が一番のバグの原因」→書類とか多い、仕様が凍結されるでもハードウェアは死ぬから運用は大変

2008年からの仮想化がハードとソフトの依存関係を切り離せるし、クラウドまで行くと運用しなくていいぜ

landing.google.com/sre

昔堅牢さ＝信頼性 AWS時代壊れる前提でオペレーションしようぜ NoOps システムに自立運用能力をもたせる壊れた前提で設計、壊れた後に治す準備までを設計しようぜ

回復性設計 azure/architecture/resiliency いかに止めないかミドルウェアに回復性を実装するのは意味わからないぐらい辛い platformにあってくれクラウドネイティブのものがいい -> Serverless (lambdaとか)

NoOps in Azure App Service

serviceについて考える

今の構成だとingressがNodeの中にあるから、リージョン跨いでサービス作ることが出来ない (例えば大阪におくとか)

地理的冗長化もかんがえる

self Healingは healthcheck死ぬとk8sがやってくれる

in-flight renewingはできない

Adaptive Scale GKEのオートスケール k8sのオートスケール、ただDB,cacheあたりはオートスケールできない正直ここだけはAWS おーろらにしたい

DB載せ替えしたいぞ

河野さん？

superriver 帝国兵

Azure console

App restartみたいなのめっちゃ良さそうログ見にいかなきゃ行けないのも見えるし、そもそも気づかないうちに起こっててハッピー

アプリケーションにも回復性をもたせたい

小さな龍後のステートレス設計非同期処理前提冪等性 -> serverlessの考え方 DevOps -> DevDevDevへ - ジョブに、キューに、ジョブを並列実行し、結果を書き込め - scoreの考え方をこれでやろう - 大量バッチの。。。みたいのがサンプルとかハンズオンにあるから見てみよう - ここかっこいい、真似したい

github.com/noops-jp

noops.connpass.com

BL もしSierのエンジニアがSRE本を読んだらエーピーコミュニケーションズあんどうともき APC pythonでAPI叩く Ansivle, Terraformに手を出したい

絶対的な力関係で無茶振り… 手順書&ダブルチェック… 依頼…非効率…

運用までシステム化したい心理的安全性を高めて生産性を高めよう

ソフトウェアエンジニアリング+サーバーネットワークインフラエンジニアやなおれじゃん！

リスク受容して信頼せ100%を目指さない SLIを本にSLOを決める、これはSLAじゃないぞ人じゃなくてデータに依る判断で標準化するエラーバジェット = 100% - SLO 開発と運用がエラーバジェットを共有

ﾄｲﾙ

手作業の繰り返しのことサービスが成長するとそうなる運用を業務の50%以下にする大きな自社サービスを展開している&高い技術を…

リスクの需要

100%という意識

SLA > SLO (1/100ならいーじゃんとはならず, ただただ0にしろと言われる)

指標となるデータが見つからない…

自動化が可能な作業かどうかが技術力に左右されるうんこ

関係者が増えるとやっばい

なんとか取り入れるやりやすい手法

50%ルール

価値の高いことをするため、時間を確保する戦略(と言い換えることで説得しやすい) 運用が100%+だしつらい運用改善すら出来ないトイルの対処 - 湯やる必要ないものは捨てる - 優先順位をつける - アウトソーシング - 代行してもらったら早かったり正確だったりする…？ - 順序のいれかえ - フローの順序が運用設計で作られるけど - ほんとにこれがただしい？を常に考える - 特殊性の排除 - イレギュラー対応、例外的な処理は非効率だし事故起きやすいし属人性高いし - 汎用的な手順で処理できるように仕様 - そうすると自動化(コードに落とす)ときにもめっちゃいいよ - 自動化 - 上記でふるいをかけたものを自動化することで正しい判断ができる - 自動化するのが目的になっちゃったり - こーどがくっちゃくちゃになったり

壁

教育学習コスト、工数、理解、、、たいへん。。。。変えるリスクをあげるのは簡単、変わらないリスクを考える必要がある

変わるべき vs 変わらないべきどっちも過大評価するないきなり議論をするな - プロトタイピング動く所をみせてメリットアピールしよう - めちゃくちゃスモールスタートして、知見と実績つもう - 人を巻き込もう

その後…

時間を確保したら - さらなる改善をする - 変化は継続しないと意味がない - そのためにスキルアップだし、それが出来てスキルアップ - トレンドおっかけようぜ

xxxx

当たり前になってる業務に新しい気付きいいものもわるいものもでてくる異なる意見もあつめようぜ、突破口になる Googleのをそのままはできない

serviceでは…

MMDUと共有することで、100なんか無理だろ!と壊れた理由言えよ!の対立を無くす正直マジでだるいから CSなんかがどんど��増えていくのはわかりきっている、自動化できるものはするお問い合わせフォームを無くすの良くない？変わらないリスクをめちゃくちゃ考える必要がある競合の新しいものが生まれたらどうする？メンバー腐る SRE読書会

加速するフロントエンド PWA 立ち見エグいめっちゃやせたな inside frontend で話したものを見てみたい mizchi　さーん node.js Rtech, freee

Reactの人ではないぞ [今]のパフォチューの常識でまっとうに作るとこんなに早いぞ serviceのプロトタイピングで作ってみようかな r.nikkei.com nikkei-inside-frontend 宍戸さんえぐい

PWAについて

本質モダンなブラウザを使うユーザーにはよりyい体験をという方向性 - serviceWorerを使ったモバイルアプリに追いつくぞ ServiceWorkerが実装されているか否か、レガシー→ IE,Safari can i use 毎回忘れるから覚える

SWについて

バックグラウンドで動くローカルプロキシあらゆるレスポンスを書き換え可能 httpsじゃないと動かない

従来のリクエスト＆レスポンスモデルの常識が通用しないぞ！！！死ぬぞ！！！すべてのものをとれんぞ UI ThreadとServerの間にServiceWorkerがいるモデル(ローカルプロキシ) リクエストから15secぐらいでsleep タブが死んでてもサーバーからのpushイベントも受け取れる、おもしろ

出来ないこと

常駐プロセスができない、 15-30秒ぐらい絵あれ Web Budget API　−メモリ使用量も制限 (Google Mozzila)

サーバーに直通だったが動的に書き換わるから…考えることが増える history.pushStateに脱線 - urlに書き戻すやつ semantic な URLをシェアするのが超大事なのがwebの世界

PWA オフライン化

オフラインキャッシュ responceをオフラインキャッシュに横流しするこれは難しい気がするな、pushで更新してそれをオフラインに横流しすれば爆速で見ることが出来たりしないかな起動自体がオフラインキャッシュでおこなわれるサーバーに依存しない形態が発生する firebaseappいいかんじ

AMPもWeb Packageng対応で再構築されるかも！？

競合

Electron chromeが Add to homescreenに… REact Native Weeb技術の Mobile App 開発環境という点で競合

インターネットがおそすぎる、一日一回だけつなぐっていいな 60fpsでうごいてほしいものだとくっそおそい先読みとかしたい、光を超えろ

初回リクエストをCDNでキャッシュオンマウスで遷移先を事前にfetch & cache レスポンスはSWのCacheから返却 dev.to 速さを最初から設計する - 更新時のcacheの履き戦略を詰めてる速さが最高��UX

IEを殺すぞ

いままではゆめ、げんじつはここから

Mobile vs Webの代理戦争じゃないの Appleはストアが良い、Googleはクロールしたいからweb, facebookは… MFI モバイルターゲットにする気持ち

PWA service workerはあってもなくても動くはずの技術 safariの 11にonfetchがあるけどonpushがない。やばい

ぱふぉちゅー

支配的なブロッキング要素を探す潰す繰り返す推測すんな計測しろ

Devtools ライトハウス preact ぴーりあくと超速webページ速度改善ガイド、買うぞ

虚無は早い重さは機能の重さ、否定するのはどうだろう

重いSQL 解像度広告

必要な速度は何でしょう。表示のスピードだけではない

k8s オラクルミッションクリティカルシステム司会はくーべるねーてるこのひとはくーばねーてす hhiroshell

本気で使うとどういうことを考えなくてはいけない？？？ ErgodoxのファームのビルドにDocker アーキテクチャー、経営プロセス

k8s を使う上で可用性の観点でやるべきこと

マイクロサービスアーキテクチャをちゃんとする - サービス境界、連携箇所に対策を施す - 疎結合にする、疎結合にするがゆえの問題があるよね - 広範囲に影響しないのでは？いやいや、する場合も多いぞ - 障害の連鎖 - Bに依存、B応答待ち、待ち側も死ぬ、Bばっか集中して死ぬ、Aも死ぬ、全部死ぬ - → サーキットブレーカーを設置 - 障害を判断して、リクエスト遮断してエラーを返すだけの子 - Istioで対処できるぞ！！ kubecon -> きゅーぶこん

Istioのおはなし

サイドカーコンテナでEnvoy アプリケーションの変更無しで入れられる、簡単便利！これいれよ IstioとCI/CDツールに依るかなりーデプロイメント - Istioでリクエストの配分率を設定可能、 1%とだけカナリーデプロイメント - istioctlでやる - CI/CDはどうなる？ spinnakerかな？ちょっとこれ後で調べる

両隣がふぁっきんかめらまんでまじでクソ

ちゃんと考慮しろ

バージョン選択

コンフィグレーション

Istioの管理・監視設定 <- これがつらそう

k8sと組み合わせる時に制約がある

あるフラグオンにするとうごかないよ… 環境作るたびにやんないといけないから大変ではある

単体の可用性を確保

従来型の障害対策を - SPOD -> 冗長化 - 障害耐性と回復性 -> 障害想定設計

ここで言うサービスとは->AP,Web,DB どこまでマイクロなんだろうかクラスタ内にMySQL　Master????, Read Replica, でデータはストレージサービスに MySQLの冗長構成 Service(ClusterIP) - read replicaにアクセス分散、スケールアウトして��ルーティングできる Service(Headless) サービスオブジェクトの使い分けで書き込み、読み込みを適切に

StatefulSet でPod配備, 落ちたら落ちた情報まま立ち上げられるマウントするストレージとか FQDNとか 1.9からGA つまりは自動再起動できるDB構成つくれんぞこれつよい read replicaのmaster昇格ができる？できなそう

%% 死なないkafka 分散メッセージ・キュー　->　これはCloud Pub/Subでいいかな透過d的な自律回復死んでる間の復旧とかリバランスとかって誰の機能でやってんの？？？？？？ Kafkaのチャットアプリ

podの名前がきれいなのはdeploymentの使い方が違うのかな… chaoskubeというツールが有る、調べる helm install labels=app=kafkaをinterval=1mごとにランダムで落とすお仕事をしてくれる kubectl logs で標準出力ログ見れるからこれでsakuraみればいいのか

リバランスの負荷高い、Zoneまたぐとき通信速度遅いので結構辛い NodeやDC自体が死んだらどうしよう

サービスメッシュ導入に必要なスキルと工数の低減

障害復旧時の負荷への対応

ノードやデータセンター障害の考慮

Oracleで実現するミッションクリティカルk8s

CNP Container Native Application Development Platform k8s周辺ツール/フレームワークを提供するやつ

CI/CD wercker(おらくるがばいしゅうしてたんだ) APIレジストリ Apiary(swaggerみたいなやつ) IaaS OKE マイクロサービスフレームワーク Istio/Envoy, Kafka, Fn Projct(OSSでつくったやつ) 管理・監視 Prometheus, Zipkin/OpenTracing, Vizceral ServiceBroker Open Service, Broker

IaaS強い Availability Domains 3リージョンの1Tb/s ホスト間低レイテンシー

性能に関するSLAをOlacleが発表ダウンタイムはほかもあるけどパフォーマンス出したの偉い

oracleにteraformのインストーラーがある

serviceでやるとどうなる？

以下をまるっと考える

Istioのおはなし

k8s を用いた最強のマイクロサービス環境をGKEで実現しよう司会はくーべねてぃす福田潔さんはくーばねーてぃす

てんえっくす 10x 1.4とか2.9倍とかじゃなくてイノベーションで10倍20倍にしようぜみたいな

GKE使ってる人ほとんど居ない問題

他のクラウドと比べて勝っている点(きゃくのやつ) - BigDataの領域強い BigQuery, Dataflow - Cloud ML (machine learning, AI) - Container (K8s)

kubectl is the new ssh kelseyhightower, kubecon 2017 keynote

かっこいいエンジニアが対象とするレイヤーがOSとかだったけど変わった低レイヤーは気にしない、kubectlでいける kubectl は全てのエンジニアが覚えろ、デファクトになんぞ

マイクロサービスアーキテクチャ, 12-factor App Zero Opsプラットフォーム

モダンな要件ユーザビリティ 24/7 アジリティ性能マルチデバイス

それを支える基盤の要素自己修復能力モジュール化スケールすることリリースパイプライン Blue/Gree, かなりあデプロイロールバックモニタリング

NOdeの自動アップグレードを設定しておこう

メンテナンスウィンドウ, beta アップグレードが行われるタイミングを決められる素敵

workerノードがVMなのでやばいヘルスチェックしたら再起動してくれる？ノードの自動修復 - Container-Optimized OSなら --enable-autorepair な感じ

マルチゾーンクラスタデフォルトでクラスタ作るとzoneはされてしまう additional zoneデマルゾーンしたい --zone asia-x-a --node-locations asia-x-b, asia-x-cみたいのできる。これやろう既存クラスタにできるし

リージョナルクラスタ(beta) masterも複数ゾーンにできるこれわからない課金されないしやるしかないっしょ

効率性 - COS(Container-Optimized OS) コス ubuntuだとジッ道アップグレードしない - スケールアウト - HPA, pod数を制御 - クラスタオートスケーラーノード数を制御 resize --sizeでおーけー、 --min-nodes 3 --max-nodes 10 --enable-autoscalingとかできる - スケールアップ - VPA Podに対するリソース割当を制御 - VMインスタンスタイプの変更 cordonする drainする既存のnodepoolを削除

プリエンプティブるVM - 中断される可能性がある - 安価 - 任意のマシンタイプいつ使うんだろう nodeSelecter　で preentible=trueみたいなのつけて運用できるランタイム-.実行基盤の意味で使ってる servie -> TCP/UDP LB, ingress -> HTTP(s) LB データストア: Spanner, Datastore, SQL DWH: BigQuery メッセージング: PubSub 運用管理: Stackdriver Logging/Monitoring CI/CD: Container Registry, Contiaer Builder GCPブログのメルカリの所あとで見る

ISP Cloiud Edge

serviceでは

ノードプールをちゃんと分けて運用する分けた先にsakuraとか配置した方がいいのでは？？？ cordon->drain->再生性、面倒だからauto-repairしようね

0 notes

helghast4 · 8 years ago

Quote

WordPressに限らず、Webサイト、いやそもそもソフトウェアというのは継続的にアップデートしていくべきである。そのためにはアップデートに強い環境を作ることが先決だ。以下のことをよく念頭においてほしい。最新環境のキャッチアップが早いホスティング企業を選ぶ。たとえばwpXやファーストサーバーはLet’s Encryptによる無料SSLに対応しており、SSL元年である2017年に対応できている。クラウドなどの変更に強いホスティング環境を選ぶ。たとえば、AWS, Azureなど。勘違いしてはいけないのだが、レンタルサーバの方がクラウドよりは月額費用が安い。クラウドを選ぶ理由は安さではなく柔軟性であり、それがお得かどうかはそのサイトの人件費に関わってくる。どうしても月500円でないといけないなら、どうしようもないのだが。開発環境とバックアップを用意しておく。アップデートの基本はやってみてダメだったら原因を特定することだ。アップデートする前に原因をあれこれ推察する��は時間の無駄である。商用環境の一発アップデートで成功しようとするのがそもそもの間違いだ。FlyWheel Localなどの記事も参考あれ。運用計画にアップデートを含める。これまで筆者は深刻な脆弱性の発見に伴っておおわらわになる現場を何度も見てきたが、そうしたリスクを事前に見積もり、運用計画に含めることだ。深刻な事態が発生したらサイトを丸一日停止させればたいていのことは解決する。もしあなたが受託仕事をしているなら、その費用をクライアントに請求しておけばよいし、そもそもすべての責任をあなたが負う必要もない。ソースコードを読んで解決しようとしない。問題が存在しないうちからソースコードを読んで安全か確認してほしいという依頼があるのだが、こんな馬鹿げたことはない。あなたは車を運転する前にいちいちエンジンルームをすべて分解して安全かどうか確かめるのだろうか？　車検や自動車保険を利用していないだろうか？　Webサイトも同じである。アップデートをしても絶対に大丈夫か聞かない。筆者はこれまで何度も聞かれたのだが……正直にいって、わからない。世の中に絶対はないのだ。もしどうしても保証が欲しければ、新宿東口に行き、占い師にお金を払うといい。きっとあなたに満足が行く答えを用意してくれるだろう。

いつWordPressをPHP7にすべきか？ - Capital P

0 notes

tak4hir0 · 4 years ago

Link

こんにちは。サイオステクノロジー株式会社でエンジニアをしております武井宜行（タケイ・ノリユキ／ @noriyukitakei ）と申します。本稿では、比較的新しいKubernetesの活用法とその実践を紹介します。 Kubernetesは、ご存じの通り、ここ数年で一気に認知度が向上したコンテナオーケストレーターであり、コンテナをプロダクション環境で動作させるための様々な機能（Rolling Updateや負荷分散など）を持ったオープンソースソフトウェアです。 Kubernetesはかなり進化のスピードが速く、取り巻く環境も常々変化しています。新しい活用法、といってもさまざまなトピックがあり迷うところですが、本稿では「The Twelve-Factor Appを援用したKubernetes設計」「Kubernetesのサーバーレス化」の2点を特筆すべきポイントとしてピックアップしたいと思います。「The Twelve-Factor App」に基づく、Kubernetesシステム設計のポイントまずはKubernetesによるシステム設計のポイントをお伝えします。最近では「The Twelve-Factor App」に従い、Kubernetesの特性を生かした設計が見られるようになってきました。「The Twelve-Factor App」とは、Herokuのエンジニアによって提唱された、モダンなアプリケーションを開発するための12のベストプラクティスをまとめたものです。もともとKubernetesのために定められた指針ではありませんが、12のうちのいくつかは、Kubernetesの構築に欠かせない重要な要素が含まれており、多くのエンジニアに参照されています。本家サイトより、12の要素を以下に記載します。コードベース：バージョン管理されている1つのコードベースと複数のデプロイ依存関係：依存関係を明示的に宣言し分離する設定：設定を環境変数に格納するバックエンドサービス：バックエンドサービスをアタッチされたリソースとして扱うビルド、リリース、実行：ビルド、リリース、実行の3つのステージを厳密に分離するプロセス：アプリケーションを1つもしくは複数のステートレスなプロセスとして実行するポートバインディング：ポートバインディングを通してサービスを公開する並行性：プロセスモデルによってスケールアウトする廃棄容易性：高速な起動とグレースフルシャットダウンで堅牢性を最大化する開発 / 本番一致：開発、ステージング、本番環境をできるだけ一致させた状態を保つログ：ログをイベントストリームとして扱う管理プロセス：管理タスクを1回限りのプロセスとして実行する上記12の中でも、Kubernetesの設計に特に欠かせないのは「設定」「プロセス」「廃棄容易性」「ログ」です。これら4項目について、具体的な事例を交えながら設計の勘どころを紹介します。【設定】ビルドの手間を減らす、設定ファイルの配置データベースの接続情報などの設定ファイルは、ソースコードを格納するリポジトリの中に保存するのではなく、環境変数で外部から与えることが望ましいです。もしソースコードに含めてしまうと環境ごとにビルドが必要になってしまうからです。例えば、ステージング用、プロダクション用にビルドが必要となり、これにデモ用など新しい環境が加わると、さらに新しいビルドが必要になってきます。さらに設定ファイルを修正するだけでもビルドが必要となるという憂き目にあってしまいます。　実際の運用では、以下の例のようにConfigMapやSecretなどに設定情報を保存し、マニフェストにて環境変数として渡します。 spec: terminationGracePeriodSeconds: 40 containers: - name: wordpress image: wordpress:php7.4 ports: - containerPort: 80 env: - name: WORDPRESS_DB_USER valueFrom: configMapKeyRef: name: wp-user key: WORDPRESS_DB_USER - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: wp-secret key: WORDPRESS_DB_PASSWORD 【プロセス】Podをステートレスにし、ユーザビリティを確保する KubernetesのPodは、スケールアウトやスケールイン、ハード障害やPodそのものの障害などによる自律復旧のため、生成や破棄を繰り返すことが前提となっています。このため、セッション情報やデータベースに格納するデータは、Podの外に永続化し、Pod自体はデータを持たない、いわゆるステートレスにするべきとされています。　仮にPod内部にセッション情報を持たせてしまうと、負荷の増減の影響でスケールアウト / スケールインし、ユーザーのリクエストが別のPodに振られると、認証のセッションが切れて突然ログイン画面が表示されるという事態になります。　実際の運用では、MySQLやRedisなどに永続化します。Azure Kubernetes Serviceの場合は、MySQLのマネージドサービスであるAzure Database for MySQL、RedisのマネージドサービスであるAzure Cache for Redisなどを使うことがあります。【廃棄容易性】Podを安全に停止する繰り返しになりますが、Podは生成や破棄を繰り返すことが前提となっています。よって破棄された後は即座に起動する必要があり、またグレースフルシャットダウンにより、サー��スを止めることなくPodを起動・破棄することが要求されます。　運用での対策として、Podが高速に起動するために、Dockerリポジトリのイメージをできるだけ小さくするという方法が挙げられます。以下は、レイヤーの数を減らすために、できるだけRUNで実施するコマンドを結合したり、aptのキャ��シュを削除するなどしてイメージの容量を削減している例です。 RUN apt-get update && apt-get install -y \ php \ apache2 \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* また、Podを安全に停止する（グレースフルシャットダウン）ために、preStopコマンドを活用します。 KubernetesのPodを終了するシーケンスは以下のようになります。 kubetctlが、Podを終了するためのリクエストをAPI Serverに送信する。 kubeletが、Pod終了のリクエストをAPI Server経由で受け取り、Podの終了処理を開始する。「サービスからPodを除外する処理」と「preStop+SIGTERMをPodに送信する」という2つの処理を同時に開始する。これらの処理は完全に非同期で行われる。事前に定義したterminationGracePeriodSeconds秒以内に3の処理が終わらなかった場合、PodにSIGKILLが送信されて、強制的に終了される。より具体的な事例として、Apacheをgracefulに停止する方法（ユーザーのリクエストを途中で切断することなく安全に停止する）を考えてみます。先述のとおり最終的にはSIGTERMが送信されますが、ApacheはSIGTERMを受け取ると、ユーザーがリクエストを送受信している途中でも強制的にプロセスを終了し切断してしまいます。これを防ぐために、preStopを使います。preStopを使うと、Podを終了する際の処理を定義でき、Apacheをgracefulにシャットダウンできるのです。その一連の処理を図解すると以下の通りとなります。最初に説明したように、Podは停止のリクエストを受け取ると、まずサービスから除外する処理を行い、該当のPodにリクエストが届かないようになります。ただし、除外処理が終わる前にApacheのgraceful shutdownが始まってしまうと、ユーザーのリクエストが処理中に切断されてしまう恐れがあるので、除外処理が終わるであろう時間（約3秒程度）sleepします。そして、サービス除外の処理によって、停止対象のPodにリクエストが振られなくなると、apachectl –k graceful-stopによって、Apacheはgracefulにシャットダウンされます。そのあと30秒ほど待ちます。これは、Apacheのリクエストタイムアウトの設定が30秒だったと仮定した場合ですが、Apacheのgraceful shutdownは非同期で行われるので、ここで30秒待機しないと、ユーザーのリクエストが終わる前にSIGTERMが送信され、処理中に強制的に切断されてしまいます。 terminationGracePeriodSecondsについては、Podの終了処理がこの値で定義した秒数以内に終わらないとSIGKILLが送信され強制的に切断されるので、サービス除外の処理（約3秒）+ユーザーのリクエストタイムアウト（30秒）＝33秒にプラスアルファして40秒としています。この設定であればPodを安全に停止でき、廃棄容易性を実現できるのです。これらの処理を実現するpreStopは以下のように定義します。 lifecycle: preStop: exec: command: ["sh", "-c", "sleep 3; apachectl -k graceful-stop; sleep 30"] 【ログ】Pod破棄に対応したログ出力前項のとおり、Podは生成と破棄を繰り返すことを前提として設計するべきです。従来のように、ログを個別のファイルに書き込んで、ローテーション……といった処理では、Podが破棄されると同時にそのログも消失してしまいます。　よってPodからは標準出力にログを出力し、そのログはflunetdなどのログコレクターに収集、ストレージに出力したり、ログのビジュアライザーなどで閲覧・分析するといった運用がベストです。　具体例を説明します。Pod内のアプリケーションのログを標準出力に出力すると、ワーカーノードの/var/log/containers以下にログがファイルとして出力されます。そのログをDaemonSetのPodとして構築したfluentd（ログコレクター）で収集し、Azureのログ管理サービスであるApplication Insightsに送信するといった運用です。 Kubernetesの“真の”サーバーレス化ソリューション現在ではマスターノードやワーカーノードの構築や運用管理が不要な、いわゆるマネージドなKubernetesがいくつかあります。AWSのElastic Kubernetes Service、GCPのGoogle Kubernetes Engine、そしてAzure Kubernetes Serviceもそのひとつです。Azure Kubernetes Service（以下、AKS）を一例に挙げますが、AKSではマスターノードは確かにフルマネージドですが、ワーカーノードの実態は仮想マシンです。そしてAKSの運用では、仮想マシンであることを意識することが必要なケースがあります。例えば、クラスタ新規構築時に仮想マシンのサイズを指定したり、ワーカーノード（稼働マシン）をスケールさせる際も同様に、スケール上限数などを設定する必要があります。ただし、実際の運用において、未来のワークロードを正確に予測して、仮想マシンの適正サイズや数を事前に設定するというのは、なかなかに困難です。この問題を解決するために、ワーカーノードさえも意識しなくてよい、本当の意味でのサーバーレスKubernetesを実現するソリューションがいくつか登場しました。その中から今回はVirtual Kubeletを紹介します。ユーザーを仮想マシン運用から開放するサーバーレスコンテナプラットフォーム Virtual Kubeletをご説明する前に、その構成の中核をなす「サーバーレスコンテナプラットフォーム」について、説明します。まずクラウド上でコンテナを稼働させたい場合にはどのようにするでしょうか。すぐ思いつくのは、仮想マシンを立ち上げ、そこにDockerをインストールし、その上でコンテナを立てる、といった方法でしょう。しかし、この方法では、「仮想マシンの運用」が必要になってきます。サーバーレスが隆盛を極める昨今、やはりこの手間は省きたいものです。「サーバーレスコンテナプラットフォーム」はこうした課題を解決するためのテクノロジーです。利用者はコンテナを稼働させるためのインフラを意識することなく、設定を定義するだけで必要なだけコンテナを稼働させることができます。コンテナを実行する基盤はすべてクラウド側で面倒を見てくれます。また、サーバーレスコンテナプラットフォームは、コンテナが実行された時間だけ秒単位で課金されます。例えば1日1時間しか動かさないバッチのために、仮想マシンを1日中動作させているのはコストのムダですが、サーバーレスコンテナプラットフォームでは、この場合1日1時間分しか課金がされず、限られたリソースの有効活用が可能です。サーバーレスコンテナプラットフォームは各社から出揃っており、AWSではAWS Fargate、GCPではServerless containers、そしてAzureではAzure Container Instancesが提供されています。サーバーレスコンテナプラットフォームを実現するVirtual Kubelet こうしたサーバーレスコンテナプラットフォームに、Kubeletが実際に行う処理を委ねる仕組みが、KubernetesにおけるKubeletの実装の一つであるVirtual Kubeletです。Kubernetesからはノードのひとつのように見えますが、従来の仮想マシンで構成されていたノードのような実態はありません。仮想的なノード内にあるVirtual Kubeletが従来のKubeletのように振る舞い、先に紹介したAzure Container InstancesやAWS FargateなどのサーバーレスコンテナプラットフォームにAPIを発行し、Pod（コンテナを格納する最小単位）を作成します。その構成は、下図のようなイメージになります。例えば、Podを100個増やすとします。仮想マシンで構成されるワーカーノードの場合、Podを100個動かすためには、ワーカーノードをスケールアップしたりスケールアウトしたりと、仮想マシンのサイズや数を意識した運用が必須になります。しかし、Virtual Kubeletの場合は、サーバーレスコンテナプラットフォームが管理するコンピューティングリソースの許す限り、Podを増やせます。必要な作業は下記のコマンド一発です。 kubectl scale --replicas=100 rs/hoge これだけでPodを100個生成できます。仮想マシンを全く意識せずにPodを作成できるーーこれがサーバーレスと表現される由縁です。 Virtul Kubeletのプロバイダー（Virtual KubeletがAPIを発行する先のサービス）は、上図に記載のAWS FargateやAzure Container Instancesの他に、Alibaba CloudElastic Container Instanceのなど多数のものが利用できます。 Azure Kubernetes Serviceによるサーバーレスの実践では、サーバーレスをいかにして実現するか。本章では実践編としてAKSを用いて、Kubernetesクラスターを構築するとともに、先程ご紹介した「irtual Kubeletによって、サーバーレスKubernetesを実現する手順を紹介します。 AKSによるKubernetesクラスターの構築まずはAKSの構築から始めましょう。本実践はAzure CLIを用いて行いますので、以下のリンクを参考に事前にAzure CLIの環境を用意してください。 Azure CLI のインストール | Microsoft Docs まず、AKSクラスターを格納するリソースグループを作成します。 $ az group create --name myAKSrg --location japaneast 続いて、AKSクラスターが配置される仮想ネットワークを作成します。 $ az network vnet create \ --resource-group myAKSrg \ --name myVnet \ --address-prefixes 10.0.0.0/8 \ --subnet-name myAKSSubnet \ --subnet-prefix 10.240.0.0/16 AKSクラスターが仮想ネットワークなどの各種リソースにアクセスできるよう、サービスプリンシパル（サービス専用アカウント）を作成します。 $ az ad sp create-for-rbac --skip-assignment { "appId": "cef76eb3-f743-4a97-8534-03e9388811fc", "displayName": "azure-cli-2020-05-30-18-42-00", "name": "http://azure-cli-2020-05-30-18-42-00", "password": "1d257915-8714-4ce7-a7fb-0e5a5411df7f", "tenant": "73f988dd-86f2-41vf-91ad-2e7cd011eb48" } また、AKSクラスターが仮想ネットワークにアクセスできるように、先程作成したサービスプリンシパルに適切な権限を付与します。まずは、先程作成した仮想ネットワークのリソースIDを取得します。 $ az network vnet show --resource-group myAKSrg --name myVnet --query id -o tsv /subscriptions/a2b379a4-5530-4d43-9360-b705cf560d75/resourceGroups/myAKSrg/providers/Microsoft.Network/virtualNetworks/myVnet 以下のコマンドで、サービスプリンシパルに権限を付与します。 --role Contributor 先の手順で作成したAKS用のサブネットに、AKSクラスターをデプロイします。そのために、このサブネットのIDを取得します。 $ az network vnet subnet show --resource-group myAKSrg --vnet-name myVnet --name myAKSSubnet --query id -o tsv 以下のコマンドでAKSクラスターを作成します。 \ -s Standard_B2s さらに、AKSクラスターに接続するための資格情報を取得します。 $ az aks get-credentials --resource-group myAKSrg --name myAKSCluster AKSクラスターの作成が完了していることを確認します。以下のようにワーカーノードが3つ表示されるはずです。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION aks-nodepool1-38191134-vmss000000 Ready agent 16m v1.15.11 aks-nodepool1-38191134-vmss000001 Ready agent 15m v1.15.11 aks-nodepool1-38191134-vmss000002 Ready agent 16m v1.15.11 続いて、このAKSクラスターにアプリケーションをデプロイしてみます。ReplicaSetのリソースを使い、ApacheのDockerイメージを元にしたPodを3つ作成します。さらに、Load Balancer Serviceを作成し、外部からアクセス可能にします。Load Balancer Serviceを作成すると、内部的にはAzure Load Balancerが作成され、Podへのリクエストが外部から到達可能になります。まず、上記の内容を実現するためのマニフェストを作成します。 apiVersion: apps/v1 kind: Deployment metadata: name: aks-sample spec: replicas: 3 selector: matchLabels: app: aks-sample template: metadata: labels: app: aks-sample spec: containers: - name: aks-sample image: httpd:2.4.43 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: aks-sample spec: type: LoadBalancer selector: app: aks-sample ports: - protocol: TCP port: 80 targetPort: 80 このマニフェストをAKSクラスターに適用します。 $ kubectl apply -f aks-sample.yml 以下のコマンドを実施して、ロードバランサーのIPアドレス（aks-sampleリソースのEXTERNAL-IP）を取得します。 443/TCP 41m にアクセスすると、Apacheデフォルトのindex.html(It works!)が表示されます。これでAKSクラスターの構築は完了です。 Virtual KubeletによるKubernetesのサーバーレス化では、先程作成したAKSクラスターをサーバーレス化してみます。まずはVirtual Kubeletによって仮想ノードを作成します。過去、Azure Container Instancesを一度も使用していない場合、Azure Container Instancesのサービスをプロバイダー登録する必要があります。登録済みかどうかは以下のコマンドで確認できます。 $ az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]" -o table コマンド実施後、以下のように表示されれば登録済みです。 Namespace RegistrationState RegistrationPolicy --------------------------- ------------------- -------------------- Microsoft.ContainerInstance Registered RegistrationRequired もし未登録の場合には、以下のコマンドを実行して、プロバイダー登録します。 $ az provider register --namespace Microsoft.ContainerInstance プロバイダーの登録が完了したら、次に仮想ノード用のサブネットを作成します。 $ az network vnet subnet create \ --resource-group myAKSrg \ --vnet-name myVnet \ --name myVirtualNodeSubnet \ --address-prefixes 10.241.0.0/16 仮想ノードを有効にするために、以下のコマンドを実施します。先ほど作成した myVirtualNodeSubnetに仮想ノードを作成します。 $ az aks enable-addons \ --resource-group myAKSrg \ --name myAKSCluster \ --addons virtual-node \ --subnet-name myVirtualNodeSubnet これで仮想ノードの作成は完了です。実際に仮想ノードが作成されていることを確認してみます。以下のvirtual-node-aci-linuxが作成した仮想ノードです。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION aks-nodepool1-38191134-vmss000000 Ready agent 84m v1.15.11 aks-nodepool1-38191134-vmss000001 Ready agent 83m v1.15.11 aks-nodepool1-38191134-vmss000002 Ready agent 84m v1.15.11 virtual-node-aci-linux Ready agent 5m55s v1.14.3-vk-azure-aci-v1.2.1.1 この仮想ノードにPodをデプロイしてみましょう。動作確認を簡単にするため、先程AKSクラスター構築の際にデプロイしたPodは以下のコマンドで削除します。 $ kubectl delete deployment.apps/aks-sample Podをデプロイするために以下のマニフェストを作成します。 apiVersion: apps/v1 kind: Deployment metadata: name: aks-sample spec: replicas: 3 selector: matchLabels: app: aks-sample template: metadata: labels: app: aks-sample spec: containers: - name: aks-sample image: httpd:2.4.43 ports: - containerPort: 80 nodeSelector: kubernetes.io/role: agent beta.kubernetes.io/os: linux type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists - key: azure.com/aci effect: NoSchedule AKSを構築したときのマニフェストとは異なるポイントが2つあります。ひとつは、nodeSelectorを指定することで、作成された仮想ノードにPodがデプロイされるようにする必要がある点です。もうひとつは、Kube-proxyなどの重要なPodが仮想ノードにデプロイされないよう、仮想ノードにはTaintsが付与されている点です。よって、仮想ノードにPodをデプロイする場合は、Tolerationsを指定し強制的に仮想ノードにPodをデプロイさせる必要があります。では、以下のコマンドで先程のマニフェストをデプロイしてみましょう。 $ kubectl apply -f aks-sample-virtual-nodes.yml ここでPodの状態を取得してみると、3個のPodが仮想ノードにデプロイされているのがわかります。 $ kubectl describe nodes virtual-node-aci-linux ・・・略・・・ Non-terminated Pods: (3 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- --- default aks-sample-6d586c44b8-4vrf9 0 (0%) 0 (0%) 0 (0%) 0 (0%) 21m default aks-sample-6d586c44b8-7n98h 0 (0%) 0 (0%) 0 (0%) 0 (0%) 21m default aks-sample-6d586c44b8-rwkk4 0 (0%) 0 (0%) 0 (0%) 0 (0%) 25m ・・・略・・・にアクセスすると、Apacheデフォルトのindex.html(It works!)が表示されます。ここでAzureポータルで、AKSクラスターのリソースグループを見てみます。マニフェストにおいてReplicaSetsで指定した3つのAzure Container Instancesが作成されています。Virtual KubeletがサーバーレスコンテナプラットフォームにAPIを発行して、Podを作成しているのがわかるかと思います。まとめ駆け足でしたが、設計、サーバーレス化の実践までKubernetesの比較的新しい活用ノウハウ��紹介してきました。繰り返しになりますがKubernetesは非常に速いスピードで進化しており、その活用法も拡大し続けています。例えば、Iot分野におけるエッジ（IoTセンサー / デバイスと、クラウドサービスの中間に位置し、集計やフィルタリングを実施手からクラウドにデータを送付する機能を持つサーバー）へのKubernetesの導入など、新たなトピックも豊富です。本稿だけでなく、ぜひ、さまざまなKubernetesの最新事例にアンテナを張り、みなさんの開発に役立ててみてください。武井宜行（たけい・のりゆき） @noriyukitakei サイオステクノロジー株式会社シニアアーキテクト。Java、PHP、サーバーレスアプリケーション、コンテナ、Azure（Functions、Azure Kubernetes Serviceなど）を得意とする。多数の登壇、ブログ『 SIOS Tech.Lab』での記事執筆は年間で100本を超えるなど、発信活動にも注力している。Microsoft MVP for Azure。関連記事編集：馮富久（株式会社技術評論社）

#エンジニアHub｜若手Webエンジニアのキャリアを考える！

0 notes

tak4hir0 · 4 years ago

Link

Coral Capitalでは先日、投資先スタートアップ企業、33社から得たアンケート調査を1枚のGoogleスプレッドシートにまとめて公開しました。アンケートは各スタートアップ企業の開発環境やエンジニア向け情報に関するもので、開発環境、仕事環境、採用情報などを会社概要と併せて30項目以上をお聞きしています。下のスクリーンショットをご覧いただければ分かるとおり、かなり大きく詳細な一覧表になっています。本記事公開より先に、Coral Capital公式ツイッターアカウントで一覧表をシェアしたところ、非常に多くの反響を頂きました。公開直後はアクセスが殺到して表示に不具合が出るほどでした。この記事では一覧表の見どころや、読み取れるポイントなどを7つの論点で整理したいと思います。これは2020年のアーリーからミドルステージの日本のスタートアップの「今どきの開発体制」のスナップショットとして見ることができるでしょうし、これからスタートアップへの転職を考えてらっしゃる大手企業やSIerの方などには参考になるのではないかと思います。 ※本企画にはjustInCaseのエンジニア小笠原寛明さん（@hiroga_cc）と、空CTOの田仲紘典さん（@hirotan__）のご協力を頂きました。注目その1：スタートアップには意外とCTOがいないエンジニアの組織に関して、まず意外だったのは、CTOというポジションがあるのは33社中17社と、ちょうど半数だったことです。残り半分はCTOが不在ということです。 CTOに続いて多かったのは「VP of Product」や「開発部長」、「VP of Engineering」といった肩書きです。プロダクトや開発チームのマネージャーや責任者という意味である肩書きを「開発責任者」としてまとめると、これは全体の24.2％にもなります。以下の通りです。 CTOとVP of Engineeringの違いを論じるブログ記事を以前掲載したことがありますが、この2つは異なる職責で、組織に両方とも設置するというトレンドが米国のスタートアップであります。CTOは最も優秀な技術者で、採用すべきアーキテクチャーを決めたりする一方で、VPoEはエンジニア組織を機能させる役割を担う、という違いがあります。こうした違いを意識するスタートアップが日本でも増えているのかもしれません。もう1つのトレンドとして、特に初期のスタートアップにおいて、CxOというポジションを用意するのを急ぎすぎない、ということもあるかもしれません。これはCFOでも同じです。アプリ開発や経理事務はスタート当初から発生しますが、最初にそれを担う人物がCxOとなるべきかというと、それは分かりません。成長するスタートアップに対して個人の成長が追いつかないことがあるというのは、良くある話です。アンケートに回答しているのはシードからミドルステージのスタートアップであることも、意外にCTOが少ないという結果に影響しているかもしれません。一方、絶対数は少ないですが、ステージ別で見るとシリーズB以降の3社には全てCTOがいました。初期メンバーに高い役職を割り振らず、事業が成長したときに外部から優秀な人材を引き入れやすくするのだと明確に公言しているスタートアップもあります。似た意見として実力派が集まる初期スタートアップにおいて、特定エンジニアが別のエンジニアよりも「上」であるという建て付けは難しいのではないかという意見もありました。「なぜ自分がCTOじゃないのか？」と、開発メンバーがそれぞれに思うからだということです。ソフトウェア・エンジニアリングの用語いえば、CTOとなるべき人物について、少なからず「遅延評価」を採用しているスタートアップが多いということではないかと思います。注目その2：目立つTypeScriptの採用開発に使っているプログラミング言語について尋ねたところ、以下のグラフのようになりました（Reactは正確には言語ではなくフレームワーク）。 1位は僅差でTypeScriptとなりました。JavaScriptの欠点を補う言語として近年人気が増しているTypeScriptですが、フロントエンドで使う場合、特にチームでの中規模以上の開発において、静的型付け言語が好まれる傾向があることを反映しているのかもしれません。また、B向けスタートアップの場合には、API課金や他社との連携においてAPIのみ提供することが増えてきたため、バックエンドと疎結合の設計とすることが多く、そのこともWebアプリケーションフレームワークが生成するJavaScriptを直接使わなくなってきている理由かもしれない、とjustInCaseの小笠原さんは指摘しています。GraphQLの利用が4社となっているのもAPI提供を前提としていることをうかがわせます。 Python、Ruby、Golangで言うと、最近のGolang人気もうかがえます。PythonがRubyより多くなっているのは、データ処理や機械学習ライブラリ利用のためもあるでしょうか。なお、より利用社数の少ない言語としては、ScalaとC#（それぞれ2社）のほかにRust、Dart、R（それぞれ1社）などもありました。今回、集計したスタートアップは比較的B向けが多く（B向け60％、C向けB向け両方21.2％）、そのためリッチなモバイルアプリ開発のためのSwiftやKotlinが少めになっている、という事情もありそうです。比較のためにエンジニア転職の専門サイトであるレバテックの2019年12月のデータを示すと以下のようになっています。注目その3：社員に占めるエンジニア比率は4〜6割、アーリーステージほど高い社員数に占めるエンジニアの割合は44％が平均でした。回答した企業の半数以上（52％）において、エンジニアの割合が40％を超えていました。やはり一般的な事業会社と比較するとエンジニアの比率が高いと言えるのではないでしょうか。また、ステージが進むとエンジニアの比率が下がる傾向も見られます。回収した回答数のNが大きくないので参考値ですが、シリーズBで27％、シリーズCで19％となっていて、特にB向けではセールスやカスタマーサクセス、Bizdevなどの割合が増えるのかもしれません。参考までに、IT系メガベンチャーで数字を見てみると、全社員に占めるエンジニアの割合はサイバーエージェントで23.3％、ビジョナルで21.2％となっています。少しデータは古いですが、2017年3月の資料によればリクルートグループの従業員4万5700人のうちエンジニアは1,700人と3.7％となっています。さらに参考値ですが、東京都の職員に占めるICT部門の職員は0.3％にすぎないそうです（ニューヨーク市は1.2％、パリは1.0％、シンガポールは7％）。注目その4：アーリーステージほど「フルスタックエンジニア」が求められる開発環境マップの一覧表には採用情報も掲載されています。サーバサイド、フロントエンド、データサイエンティスト、iOSエンジニア、SREといった区分です。初期段階のシードやプレシリーズAにおいて「フルスタック」もしくは「フルス��ックがのぞましい」と応募としている会社の割合は40％以上にのぼるのに対して、シリーズAでは27.3％となり、シリーズB以降ではゼロとなっています。初期には何でもできるエンジニアが求められるのに対して、ステージが進むと専門化が進む様子がわかります。シリーズCのSmartHRで見るとQA（Quality Assurance）エンジニアやセキュリティーエンジニアなどのポジションの応募も見られます。どんどん新しい技術に触れてゼロイチで作っていきたいのか、じっくりと専門性の高い部分で経験を活かしたいのかということは、転職先のスタートアップ選びで重要な観点かもしれません。注目その5：開発手法は、ほぼアジャイル開発手法に「アジャイル」を採用していると回答したのは33社中32社にのぼりました。このうちウォーターフォールを併用しているのが3社。ほかに興味深い回答としては、Authleteの「特に意識している開発手法なし」というものもあります。「進捗管理や納期設定もなく、気が向いたときに各人のペースで開発しています。しかし、新仕様実装は業界内で常に一、二を争うほど早いです」との回答でした。カンバンやスクラムなどを、アジャイルの具体的な方法論を上げる会社が多いのですが、エンジニアの数が50人を超えているSmartHRの1社だけ「LeSS」（Large-Scale Scrum）を挙げています。これはスクラムが主に1チームの話であるのに対して、複数チームにスケールするためのフレームワークだそうです。注目その6：ピュアGCPが2割超えスタートアップといえば、AWSという時代が長く続いていましたが、最近はGCPを併用するケースも増えているようです。特にBigQueryを使うためとか、Firebaseを使いたいなど個別機能を理由にマルチクラウドという選択肢を取るところもあります。HerokuやAzureを併用する会社も、それぞれ2社ありました。 GCPを併用するスタートアップは多く、33社中13社と4割にのぼりました。さらに「GCPのみ」と回答したスタートアップは33社中7社ありました。これは全体の21％に相当し、5社に1社がAWSを使わずGCPを利用していることが分かりました。さらにシード期に限っていえば、10社中4社がGCPのみと回答していて、その割合は40％になります。 GCPを選択する理由として良く聞くのは、どうせBigQueryを使うのであればGCPに統一したいとか、新しいテクノロジーへの興味がある、AWSは利用者が欲しいものを作るので機能が多すぎて把握しきれないといったものがあります。注目その7：GitHubが90.9％で圧勝ソースコード管理では、GitHubという回答が全体の90.9％を占めました。GitHubのオープンソース実装とも言えるGitLabを併用しているケースをのぞいて、GitLabだけを使っている会社も2社ありました。また、Bitbucketが1社ありました。かつてGitHubはプライベートリポジトリが有料プランのみで、そのことから数年前の初期スタートアップでは「JIRA＋Bitbucket」という組み合わせも一定の人気がありました。それが、GitHubでもプライベートレポジトリが無料となったことが影響しているのかもしれません。また、スピードが命のスタートアップでは開発・運用の方法論としてアジャイルに加えてCI（Continuous Integration：継続的インテグレーション）やCD（Continuous Delivery：継続的デリバリー）を実践するところが多いかと思います。ソースコードを改変したら、その都度バグや不具合がないかを自動で検査してクラウドへ展開するところを自動化する、ということです。2019年11月から「GitHub Actions」という機能が利用可能となり、標準機能としてGitHubでCI/CDが利用できるようになりました。こうしたことからも、GitHubの一強時代は当面変わることがなさそうです。さて、以上、スタートアップの開発環境を数字で見てきましたが、アンケート結果にはこの他にも、リモートワークや副業の可否、エンジニアが気になる機材・書籍購入の補助といった仕事環境についても詳しい情報があるほか、エンジニアとして働く魅力についても自由記入として詳細にご回答いただいています。また今週、新たな追加質問により「開発環境マップver2」にパワーアップしています。各社エンジニア社員のプロフィール（GitHubやTwitterアカウント）、各社エンジニアの出身企業、各社おすすめ書籍やツールなども会社ごとのタブにより追加されています。募集中のポジションや選考を受けたい方向けの連絡先もありますので、スタートアップでエンジニアとして働くことに興味のある方は、ぜひ「スタートアップ開発環境マップver2 by Coral Capital」を、ご覧くださいませ。

#Coral Capital

0 notes

tak4hir0 · 5 years ago

Link

LINE API Expertは、LINEが開発者向けに提供する各種APIなどへの深い理解と高い技術力を持ち、開発者コミュニティに影響力を持つエンジニアの方々を認定し、様々な特典を提供すると共に、その活動を支援するプログラムです。審査基準は、コミュニティへの影響力、記事執筆やプレゼンテーション能力、関連ソフトウェア開発における技術力、将来の技術パートナーとしてのポテンシャルなどの観点で、総合的に判断しています。今回も多数の応募者の中から認定した新たなメンバーをご紹介します。今回は、日本、タイから合計7名を認定しました。新たなメンバーによる積極的な情報発信やLINE Developer Communityの盛り上げ等を期待しています。日本後藤勝哉さん後藤さんは、2013年8月に参画した株式会社エウレカにて、「Pairs」&「Couples」のネイティブアプリ開発を担当されていました。その後、2019年に株式会社Entaleを創業されています。株式会社Entaleでは、LINE公式アカウントを活用したペアケアの運用・開発をされています。サービスの企画・開発、グロースの観点でどのようにLINEの技術を活用しているのか、実績や良し悪しも含めて多くの情報発信をしてくださることに期待しています。中嶋一樹さん中嶋さんは、エバンジェリストとして、LINE含め複数のグローバルIT企業で活躍された経験をお持ちです。短期間で優れたプロトタイプ・サービスを企画開発し、情報発信を進めることを強みの１つとしており、salesforce.com在籍時には開発したアプリケーションが世界中で最もダウンロードされるなど、デモという枠を超え、実際に使われるアプリケーションであることを重要視した開発・啓発活動を行った実績をお持ちです。2019年に株式会社Bot Expressを創業され、「役所のもう一つの窓口をLINEに開設する」というコンセプトを具体化したサービス「GovTech Express」を開発されました。LINEとして最適なユーザー体験は何か、運営主の利便性に配慮したサービス設計や運用の仕組みについて、随時ご紹介いただけたらと考えています。中村優輝さん中村さんは、クラスメソッド株式会社でCX事業本部 LINE Solution Architectとして活躍されています。AWSのサーバーレスサービスを利用したアプリケーション開発に従事し、LINEの技術を事業会社で活用するためのソリューション提案・SaaSのプロダクトオーナーを担当されています。オウンドメディアでは、積極的な執筆活動やイベントで登壇者として情報発信をされており、今後も継続的にLINEのプロダクトを活用した実践的なソリューションの提案や問題定義をしてくれることに期待しています。平林拓将さん平林さんは、人材派遣会社のテクニカルトレーナー兼開発者であり、さまざまなIT技術の研修やハンズオンの企画・講師を務める傍ら、クラウドを活用したシステムやLINE Botの開発を担当されています。Microsoftの技術(C#やAzureなど)も好まれており、LINEの技術とMicrosoftの技術を連携した実装例の紹介やSDKの開発やコントリビューションを行っています。LINEが提供するAPIの活用方法を見つけ、対外的な情報発信を通じて、平林さんの強みを生かした技術啓発に寄与してくれることを願っています。松本典子さん松本さんは、株式会社オルターブース所属し、Microsoft MVPでもあり、ユーザー指向でのUX、CI / VIデザインを得意とするデザイナーです。Microsoftが提供しているiPaasサービスのAzure Logic Apps / Power Automate(Flow)を利用して、ノンコーディングでLINE Botを作成する方法やデザイナー視点でのMicrosoft Azureの活用方法を積極的に紹介してくださっています。ASCII.jpへ技術紹介記事の寄稿等も行っており、所属問わず、デザイナーとして最適なユーザー体験の提案や、構想、情報発信に期待します。 ASCII.jp 連載記事一覧「Azure Logic Apps」超入門～AI編～・「Azure Logic Apps」超入門三浦耕生さん三浦さんは、エンジニアとして関西(名古屋)で活躍されています。LINEのAPIとIBMの技術(Watson Assistantなど)を組み合わせたBot開発や、勉強会の企画、講師を推進されており、2020年1月には、IBM Champion 2020に選出されました。 LINEの新しい技術とともに他社の優れた技術を交えたインプットとアウトプットを推進いただきながら、LINEのAPI啓発活動に貢献いただけることを願っています。タイ Mr. Pamorn Trivorrara 多くの応募者の中から厳選なる審査を行い、国内外含めて合計7名をLINE API Expertの新メンバーとして認定いたしました。この度、新メンバーに認定されなかった方も、引き続き積極的にご活躍いただき、次回の認定に臨んでいただけたらと思います。LINE API Expertのメンバーの皆さまの飛躍的な活躍と、LINEのDeveloper Communityがより一層盛り上がることを願っています。全国のAPI Expert情報は、全国のAPI Expert情報は、こちらに一覧で掲載しておりますのでぜひご覧くださいLINE API Expertへは、こちらのページよりご応募ください

#LINE ENGINEERING

0 notes

tak4hir0 · 5 years ago

Link

2019年度 IaaS ワークショップ @ NTTコム 1. IaaSワークショップ @NTT Communications @iwashi86 2019.4.15 2. Day3-5(3⽇間)の流れ・IaaS/CaaS/FaaSを⽤いて同じ仕様のWebアプリを作成・今回の研修の本質はアプリではない・本質は・どうクラウドを使いこなすか？・サービス(お客様価値)をどう作り上げるか？・クラウドはそのための強⼒な武器 3. 今⽇(IaaS)の流れ・講義: 1-1.5h 程度・クラウド、IaaSについて・注: 知識量が多く駆け⾜なので、気になるところは別途確認のこと 4. 今⽇(IaaS)の流れ・講義: 1-1.5h 程度・クラウド、IaaSについて・注: 知識量が多く駆け⾜なので、気になるところは別途確認のこと・実習: 残り時間全て・IaaSクラウドデザインパターンの実装・簡易カオスエンジニアリングに耐える 5. 講義の流れ 6. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ 7. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ 8. そもそもクラウドとはなにか？ NISTによるクラウドコンピューティングの定義 https://www.ipa.go.jp/files/000025366.pdf （最近だとちょっと古い感じの内容 + 少しお硬いので…） 9. ・対照的なのはオンプレ・⾃社でサーバを抱えること・クラウド ⇒ 抱えない・オンデマンドで必要なときにリソース確保・コスト・オンプレ：将来を予測して投資・クラウド：必要なだけ払う（⼤量に使った場合はむしろ⾼いことも）そもそもクラウドとはなにか？ 10. クラウドを提供するサービス達・GCP / Google ・AWS / Amazon Web Services ・Azure / Microsoft ・ECL 2.0 / NTT Com 11. クラウドの分類① ・IaaS / Infrastructure as a Service ・もっともベーシック・他を⽀える基礎として抑えておくのが重要・IaaSが向いている機能もある・VM、ネットワーク、ストレージを貸出・PaaS / Platform as a Service ・アプリ＋ミドルウェア以外をマネージ・HerokuやGoogle App Engineが有名 12. クラウドの分類② ・CaaS / Container as a Service / 詳しくは明⽇・コンテナの実⾏基盤を提供・主流は Kubernetes をマネージ・GKE / EKS / AKS と各社出している・FaaS / Function as a Service / 詳しくは明後⽇・関数の実⾏環境を提供・AWS Lambda、Google Cloud Functions など・SaaS / Software as a Service、GitHubとか 13. レイヤで分類⽐較してみる 14. オンプレは全部やる、データセンタすら作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレ⾃社は事実、データセンタを多く構築している 15. ホスティングはデータセンタ内のサーバを拝借データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプ 16. IaaSはOS以上をユーザがやるデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS 17. CaaSはコンテナ以上をユーザが対応データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS 18. PaaSはアプリだけ⾃分で作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS 19. FaaSは関数だけ⾃分で作るデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS 20. SaaSは使いたい機能だけデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ SaaS 21. それぞれに向き不向きがあるデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージオンプレデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージホスティングデータセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ IaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ CaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ PaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ FaaS データセンタ物理サーバ仮想化 OS コンテナ実⾏環境アプリ関数データネットワークストレージ SaaS ⼤ ← ⾃由度 → ⼩⼤ ← ⼯数→ ⼩ 22. 参考: 使い分けはCNCFのホワイトペーパーがオススメ https://github.com/cncf/wg-serverless 23. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ 24. IaaSの得意領域・既存のシステム移⾏・特定のOS/Kernelに縛りがある・GPUが必要・HTTP/S以外のプロトコル 25. IaaSでは・GUIをポチポチ or APIを叩くと VMが上がる + NW とストレージが付属 26. IaaSでは・GUIをポチポチ or APIを叩くと VMが上がる + NW とストレージが付属・NWもまるごと設計できるので⾃由度は⾮常に⾼いその半⾯、イマイチな設計もしやすい (クラウドの⼒を使いこなせない) 27. ではどうするか？・もともと有名なやつ（と類似の概念で…） 28. クラウドデザインパターン(CDP)へ補⾜: AWS版だけど、他クラウドでもほぼそのまま応⽤できる http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 だいたい2013-2015年ぐらいに流⾏していた（今も現役で動いているものは多いはず） 29. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ 30. InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知これを作りたい、さてどうしよう？ 31. もし研究室でやるなら VM App + DB ・サーバ(VM)を1台たてる・Webサーバ(nginx) ・Rails/Djangoとかでロジック・MySQLやPostgreSQLにデータを保存・落ちたら苦情ドリブンで復旧・全部とぶとヤバいのでたまにRDBのバックアップをとる 32. お仕事でやる場合の重要概念 33. SPOFを避ける・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」・その単⼀箇所が働かないとシステム全体が障害となるような箇所補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある 34. SPOFを避ける・SPOF / Single Point Of Failure ・⽇本語だと「単⼀障害点」・その単⼀箇所が働かないとシステム全体が障害となるような箇所・解決⽅法の例・冗⻑化・落ちても⾃動復旧させる補⾜) 全てSPOFを避けるのではなく、費⽤対効果でSPOFを許容するケースもある 35. IaaS x Webアプリ x CDP 36. 最初の構成 VM App + RDB 37. 圧倒的に重要なDBを冗⻑化 App RDB (Primary) RDB (Secondary) Primaryが落ちたら SecondaryをPrimaryに昇格し接続先を切り替え 38. 障害時はFailOver Master/Slave(Slaveという⾔葉がいまいちなので最近使わない) ・使うDBの種類、プロダクトによって異なる 39. Appも冗⻑化していく App RDB (Primary) RDB (Secondary) App 40. 参考: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・・・スケルアウトスケルイン 41. どうやってAppにリクエストを振り分ける？ App RDB (Primary) RDB (Secondary) App 42. 代表的案な2⽅式 43. 代表的案な2⽅式 44. 結果的にこうなる App RDB (Primary) RDB (Secondary) App LB LB DNS ラウンドロビン・IaaSを使った場合の超基本形 45. さらにマネージドサービスを使うと… App App DNS ラウンドロビン※ クラウド提供LB クラウド提供DB ※ クラウドによってラウンドロビンするかは異なる GCPの場合は、単⼀IPアドレスでIPエニーキャストで対応 46. 参考: Cloud Load Balancing(GCP Managed LB) 47. 参考: Cloud SQL(GCP Managed RDB) 48. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・冗長化について・カオスエンジニアリング講義の流れ 49. 冗⻑化したときのハマりどころ 50. 50 App(Rails) App(Rails) ①ログインログインを考える 51. 51 App(Rails) App(Rails) ①ログイン ②セッションキャッシュログインを考える 52. 52 App(Rails) App(Rails) ①ログイン ③GET ログインを考える ②セッションキャッシュ 53. 53 App(Rails) App(Rails) ①ログイン ③GET ④キャッシュが無くてアクセスがコケるログインを考える ②セッションキャッシュ 54. 54 ①スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる代表的な対応策 x 2 55. 55 ①スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる ②セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチ・スケールイン/アウトに対応しやすいから代表的な対応策 x 2 56. 56 App(Rails) App(Rails) ①ログイン ②セッション ③GET ④セッションを取りに⾏く KVSとか ②セッションを書き出すセッションを外に出した例 57. 57 CDP: State Sharingパターン http://aws.clouddesignpattern.org/index.php/CDP:State_Sharing%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3 58. 58 ・スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる・セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチ重要な概念 59. 59 ・スティッキーセッション・ロードバランサなどを利⽤してセッションを払い出したアプリサーバと同⼀のアプリサーバに常に接続させる・セッションの状態を外に追い出す・KVSなどを利⽤してセッションを追い出す・クラウドを活かすならコッチスケールアウトさせるときの肝＝いかに状態/ステートを外にだすか？閉じ込めていくか？ (この概念はコンテナ時代でも重要) 重要な概念 60. 60 ①APP ②RDB ③KVS ④Other ユーザが写真を投稿したらどこに保存？ 61. 61 ①APP ②RDB ③KVS ④Other ①APP 状態を追い出す、閉じ込められてない例 ①はNG、リクエスト先によっては存在し��い 62. 62 ①APP ④Other ④が多い、よく使うのはオブジェクトストレージ⾃社クラウドであるCloudnのオブジェクトストレージへ貯め込む例 63. 冗⻑化のめんどくささ 64. 冗⻑化対象は⾊々とある・RDB (MySQL/Postgres/Oracle/…) ・KVS (Redis/…) ・LB ・全部やるのは⾮常に⼤変・ちゃんとFailoverするの？コネクションは？・直接、お客様価値につながらない部分・Instagramだったら、ここは本質ではない・そもそも、その価値(仮説)が刺さるか謎 65. そこで各クラウドプロバイダはマネージドを⽤意・RDB ・AWS RDS ・GCP CloudSQL ・KVS ・AWS ElastiCache ・GCP / Cloud DataStore ・LB ・AWS ALB/NLB/CLB ・GCP LB (その他、SQLで扱えるDBは⾊々あるが割愛) ・⾃動で対応・セキュリティパッチアップデート・冗⻑化・バックアップ 66. そこで各クラウドプロバイダはマネージドを⽤意・RDB ・AWS RDS ・GCP CloudSQL ・KVS ・AWS ElastiCache ・GCP / Cloud DataStore ・LB ・AWS ALB/NLB/CLB ・GCP LB (その他、SQLで扱えるDBは⾊々あるが割愛) ・⾃動で対応・セキュリティパッチアップデート・冗⻑化・バックアップ重要なのはサービス・プロダクトの本来の価値にリソースを集中すること (サボれる部分はサボる) 67. どこまで冗⻑化するか？ 68. 冗⻑化の単位・HDD/SSD単位(RAID) ・サーバ単位・ラック単位・データセンタ単位、Availability Zone単位・リージョン単位・クラウド単位結局、サービス・プロダクト特性にあわせて検討 69. スケールアウト/イン or スケールアップ/ダウン 70. 再掲: スケールアウト/スケールイン App RDB (Primary) RDB (Secondary) App App ・・・スケルアウトスケルイン 71. スケールアップとダウン・スケールアップ・CPUの数を増やす、メモリを増やす・スケールダウン・CPUの数を減らす、メモリを減らすなお… 現代は、スケールアウトを上⼿く使うのが主流 (スケールアップ/ダウンも使わないわけじゃない、使い分け) 72. 12 Factor Apps https://12factor.net/ja/ 73. I. バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係を明⽰的に宣⾔し分離する III. 設定を環境変数に格納する IV.バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実⾏の3つのステージを厳密に分離する VI.アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する VII.ポートバインディングを通してサービスを公開する VIII.プロセスモデルによってスケールアウトする IX.⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する X. 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ XI.ログをイベントストリームとして扱う XII.管理タスクを1回限りのプロセスとして実⾏する参考: 12 Factor Apps の各項⽬ 74. I. バージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係を明⽰的に宣⾔し分離する III. 設定を環境変数に格納する IV.バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実⾏の3つのステージを厳密に分離する VI.アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する VII.ポートバインディングを通してサービスを公開する VIII.プロセスモデルによってスケールアウトする IX.⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する X. 開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ XI.ログをイベントストリームとして扱う XII.管理タスクを1回限りのプロセスとして実⾏する参考: 12 Factor Apps の各項⽬微妙にイメージが湧きにくいので、たとえばAWSなら 75. https://www.slideshare.net/AmazonWebServicesJapan/the-twelvefactor-appaws 76. https://codezine.jp/article/detail/10402 77. 少し戻って… 78. 再掲: InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知 79. 再掲: InstagramみたいなWebアプリを想像・まず、HTML/JavaScript/CSSを取得・ユーザ登録・ログイン認証・画像やコメントの投稿・修正・閲覧・当然、それらは保存される必要がある・ユーザのAppへPush通知 ⇒ ⼀度に⼤量配信すると処理溢れで捌けなくなることも… 80. Queueを挟んで分散する Queue App App 送りたいタスクを⽣成(Produce) 配信App 配信App Queueからタスクを取得して配信 (Consume) 81. ・クラウド全般の知識・IaaSについて・Instagramライクなアプリの設計で学ぶ・カオスエンジニアリング講義の流れ 82. https://www.oreilly.com/ideas/chaos-engineering 83. カオスエンジニアリングとは “Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the systemʼs capability to withstand turbulent conditions in production.” ・分散システムにおいて・本番環境のように荒れる環境にも耐える能⼒を持っている・という確信を得るための実験/検証の規律 84. どのようなことをするか？・(⼀番有名なものだと）商⽤のVMをランダムで落とす・リージョンやデータセンタ単位で障害を起こす・あるトラフィックに対して⼀定期間レイテンシを増加させる・ある関数がランダムに例外を投げるようにする・システム間の時刻をずらす・デバイスドライバでI/Oエラーを起こす・クラスタのCPUを最⼤限まで使い切る 85. なぜこんなことを？・お客様価値を落とすシステムの弱みを学びそれを改善することで、システムの信頼性を⾼められるから（実際に障害を起こさないと分からないことは⼭程ある…） 86. カオスエンジニアリング適⽤の前提条件・シンプルな質問に答えられるか？「あなたのシステムは、サービスの障害やネットワークレイテンシの急激な上昇といった現実世界の出来事から回復できるか？」もし、no なら先にやることがある。・⾃分のシステムの状態を監視できているか？ + Steady State(正常な状態) を定義できているか？ 87. 再掲：実習では少しだけ味⾒してみる (カオスエンジニアリングの⼀部だけ体験してみる) ・(⼀番有名なものだと）商⽤のVMをランダムで落とす ← 採⽤・リージョンやデータセンタ単位で障害を起こす・あるトラフィックに対して⼀定期間レイテンシを増加させる・ある関数がランダムに例外を投げるようにする・システム間の時刻をずらす・デバイスドライバでI/Oエラーを起こす・クラスタのCPUを最⼤限まで使い切る 88. 現実世界ではもっと考えることがある 89. たとえば… ・運⽤って何やるんだっけ？・冗⻑化してても落ちたら？・依存しているAPIが不安定に… ・使ってるライブラリの脆弱性が⾒つかった？・あれ、そもそも監視って何やるんだっけ？ ⇒ トピックはいくらでもあるので書籍、オンライン資料、実務で⾝につける 90. （参考）個⼈的にいくつか良いクラウド向けの勉強リソース/書籍 91. https://www.oreilly.co.jp/books/9784873118642/ ⼊⾨監視 92. https://www.slideshare.net/AmazonWebServicesJapan AWS Black Beltシリーズ 93. https://cloudplatformonline.com/onair-japan.html Google Cloud OnAir 94. まとめ 95. 本⽇お話したこと・クラウドとは？IaaSとは？・Instagram的なアプリを作る⽅法・CDPを使う・マネージドを使う・カオスエンジニアリングおしまい！（質問があれば！）

#SlideShare

0 notes

tak4hir0 · 5 years ago

Link

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス著者／訳者：David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士出版社：オライリージャパン( 2019-9-18 ) 定価：￥ 3,132 レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。業務システムクラウド移行の定石著者／訳者：吉羽龍太郎出版社：日経BP社( 2018-7-12 ) 定価：￥ 3,456 業務システムをAmazon Web ServicesやMicrosoft Azureに移行する手順を企画フェーズ、戦略・分析フェーズ、PoCフェーズ、設計・移行フェーズ、運用フェーズの5段階に分けて解説しています。たくさんの業務システムを効果的にクラウド移行する方法を探している方に最適です Effective DevOps ―4本柱による持続可能な組織文化の育て方著者／訳者：Jennifer Davis、Ryn Daniels / 吉羽龍太郎、長尾高弘出版社：オライリージャパン( 2018-3-24 ) 定価：￥ 3,888 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】著者／訳者：Gary Gruver、Tommy Mouser / 吉羽龍太郎、原田騎郎出版社：技術評論社( 2017-1-25 ) 定価：￥ 2,138 米ヒューレット・パッカードのLaserJet部門でいかにしてAgileやDevOpsの原則を適用しマーケットの変化に対応できるようになったかの事例を解説。巻末には日本の大手企業の事例も収録ジョイ・インク役職も部署もない全員主役のマネジメント著者／訳者：リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸出版社：翔泳社( 2016-12-20 ) 定価：￥ 1,944 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています Amazon Web Services企業導入ガイドブック著者／訳者：荒木靖宏, 大谷晋平, 小林正人, 酒徳知明, 高田智己, 瀧澤与一, 山本教仁, 吉羽龍太郎出版社：マイナビ出版( 2016-06-10 ) 定価：￥ 2,797 AWSを企業に導入する際に知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用までをまとめた書籍。操作の仕方ではなくどのように導入していくかの考え方や設計方法に焦点をあてていますアジャイルコーチの道具箱 – 見える化の実例集著者／訳者：Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也出版社：Leanpub( 2016-04-12 ) 定価：$14.99 この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集ですカンバン仕事術 ―チームではじめる見える化と改善著者／訳者：原田騎郎安井力吉羽龍太郎角征典高木正弘出版社：オライリージャパン( 2016-03-25 ) 定価：￥ 2,138 チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍です。カンバンの原則や流れの管理などの入門的な事柄から、サービスクラス、メトリクスの使用、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。カンバンを一から学びたい、組織で使ってみたいと考える方に最適な実践的な入門書��す。サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] 著者：吉羽龍太郎新原雅司前田章馬場俊彰出版社：技術評論社( 2016-02-26 ) 定価：￥ 2,138 DevOpsの基本と主にツール面からの解説。Ansibleによるサーバ管理、CircleCIでの継続的インテグレーションフロー、Dockerの話まで幅広いトピックを扱っています SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人永瀬美穂吉羽龍太郎出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション著者／訳者：渡辺一宏吉羽龍太郎岸田健一郎穴澤康裕出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによるインフラ構築の自動化 (WEB+DB PRESS plus) 著者／訳者：吉羽龍太郎安藤祐介伊藤直也菅井祐太朗並河祐貴出版社：技術評論社( 2014-05-22 ) 定価：￥ 2,992 スタンドアロンでのChef Soloの利用から始めて、クックブックの書き方や注意すべきポイント、さらにはクックブックのテスト、継続的インテグレーションなど幅広いトピックを解説 Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド著者／訳者：Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳出版社：アスキー・メディアワークス( 2013-03-08 ) 定価：￥ 1,680 スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明 How to Change the World 〜チェンジ・マネジメント3.0〜著者／訳者：Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳) 出版社：達人出版会定価：500円どうすれば自分たちの組織を変えられるだろう？それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック

#Ryuzee.com

0 notes

tak4hir0 · 5 years ago

Link

はじめに個人開発というのはやはり難しく、サービスのアイデアを考え、設計し、実装して、運用するといった過程の中で何度も壁が立ちはだかります。その内容は技術面、マインド面、環境面など様々です。今後も個人開発を続けていく中で、自分はもちろん他の開発者さんが同じ壁にぶつからないよう、また、ぶつかってもすぐに乗り越えられるよう、僕の経験ベースでその壁の乗り越え方をシンプルに淡々とまとめていきたいと思います。誰もが一度はぶつかるであろう壁から、それあなただけでしょって壁まで様々ですが、少しでも参考になったら嬉しいです！筆者についてサービスを作るのが趣味で普段からWebサービスをゼロから作って、育てて、時には壊してというのを繰り返しています。最近はアプリ開発の方も頑張ってます。 1年前はこんな記事も書きました。もっと気軽にアウトプットできる技術ブログサービス「Qrunch（クランチ）」をリリースした Qiitaに投稿するのはそれ以来なので若干緊張気味です。ぜひお手柔らかにお願いします目次この記事は以下の構成でお届けします！その1. そもそもアイデアが思い浮かばない遭遇確率　：★★★★☆ どんな壁？：いざWebサービスを作ろうとしても何もアイデアが思い浮かばない解決策：身近な課題をひたすら探すサービスを作る上では何かを解決する系のアイデアであり、かつ自分が当事者であるとモチベーションも続きやすいです。自分が普段ネットを使っていて不便だと思うこと、今使っているサービスの不満点、などなんでも良いのでとりあえず書き出してみましょう。大体この中に自分の技術力でも解決できるような課題が存在します。もし自分の中での課題が見つからないという場合は、日々Twitterのタイムラインで流れてくる身近な人が抱えている課題をピックアップしてアイデア化するのもありです。回避策：しょぼいアイデアでも日々書き残していくいざサービスを作るというときにアイデアも出ないし身近な課題すら見つからない場合は、普段からアイデアを無理やり出して書き残しておく癖をつけると良いです。上の画像は以前僕がNotionでまとめていたシートの例です。この時は「1日3個のアイデアを生み出す魔法のシート」と名付けて、どんなにしょぼいようなアイデアでも毎日朝・昼・晩の3個出してメモし続けるようにしていました。結果、アイデアを考える癖というものがかなり身に付きましたし、その中からも何個か形にして現在も成長してるサービスもあります。アイデアが考えれない方はぜひ参考にしてみてください。そのうち100、200とアイデアが溜まっていき、気づいたらかなりな資産になっています。その2. モチベが続かずリリースまで辿り着けない遭遇確率　：★★★★★ どんな壁？：アイデアは思いつき実装に取り掛かったものの、途中でモチベーションが続かなくなり結局プロジェクトを放置してしまう回避策：まずデプロイしてしまう Webサービスを開発する上では、ローカルでひたすら作りこんである程度完成したらデプロイしてリリースという流れが一般的ですが、この方法だと最後のデプロイに辿りつく前に力尽きて投げ出してしまうというパターンに陥りやすいです。ということで僕は最低限の環境構築ができたらまずデプロイしてしまうということをしています。これによって、サービスをリリースするということに対するハードルがかなり下がり、開発途中でモチベが下がるということも相当減りました。なお、このパターンを採用する際は最低限のベーシック認証とクローラー拒否設定は必ずしておきましょう。 <meta name="robots" content="noindex" <meta name="robots" content="nofollow" 回避策：覚えたての技術の練習場所にしないこれは自分もよくやってしまうのですが、エンジニアは何か新しい技術を覚えた際に「せっかくだからこの技術を使ってサービスも作ってしまおう」という考えになりがちです。サービスを作る目的が「技術力の向上」なのであれば良いですが、「ユーザーに何らかの価値を届けること」が目的なのであれば、やむを得ず新しい技術を使う場合以外、絶対に慣れた技術を使ったほうが良いです。僕は今まで、ユーザーに何らかの価値を届けることが目的だけどついでに新しい技術も習得しちゃおうなんてことを何度もやってきましたが、それらのプロジェクトはほぼ全て途中で疲れて辞めちゃいました。サービスを作る上での目的をブレずに持ち続けるべきです。その3. 開発リソースが足りない・時間が足りない遭遇確率　：★★★★☆ どんな壁？：授業や仕事で個人開発の時間がとれない。開発リソースが足りずに全く進捗がでない回避策：どこで妥協するかを決めておくある程度プログラミングに慣れてきた段階にいる時こそ、完璧を追い求めがちになってしまい、あれもこれも自分の手で作って結局手一杯みたいなことになりがちです。サーバー管理が面倒なのであればHerokuを使ってもいいですし、本来自動で処理すべき機能も始めは手動でリリースして余裕ができてから自動化してもOKです。極論、テストコードだって必要性を感じるまでは書かなくてもOKです。サービスの本質的でない部分はどんどん手を抜いて、後から余裕ができたら補強していくという考え方がベストだと思います。回避策：技術的な資産を作る・使う多少のデザインは違えど、Webサービスは「使い回せるパーツ」が数多く存在するので、そういったコードは汎用性を持たせた状態でGitHubリポジトリかなんかに保存させておいて、使いたい時にコピペして使い回せるようにしておきます。また、自分はよくRailsを使ってサービスを作るのですが、「外部ログイン機能を持ったSNS系サービスのRailsプロジェクト」「テキスト投稿系サービスのRailsプロジェクト」というように後々同じ形式のサービス作りそうだなと思った時点でパッケージ化してこれもGitHubにあげちゃいます。それに加えて、開発環境や本番環境、DBなどのインフラ部分は必ずDockerコンテナの上に載せて、これも汎用的なものがあればイメージをexportさせて使い回せるようにさせています。 docker export example-container example-container.tar こうすることで無駄なコーディングを減らし、サービスづくりの本質的な部分にちゃんと労力を掛けることができるようになるので個人的におすすめです。その4. 明らかに”個人開発”なデザインになってしまう遭遇確率　：★★★★☆ どんな壁？：サービスのデザインが上手くできず、フレームワークを駆使した結果いかにも “個人開発” な見た目になってしまった回避策：Bootstrapから脱却する “個人開発” なデザインを別の言い方に直すと “よくあるBootstrapぽいデザイン” になります。 Bootstrapは、レスポンシブ対応で配色パターンも指定されており、チーム開発の現場でも効率的に実装を勧められるなどメリットが沢山ありますが、CSSのサイズが膨大だったり、jQuery依存な箇所があったり、既に指定されているスタイルが邪魔をして逆にカスタマイズしにくいなどといったデメリットも多いです。慣れないはじめのうちはBootstrapを使ってもよいですが、出来るだけ早めにCSSを習得してフルスクラッチまたは軽量フレームワーク + スクラッチのどちらかに移行したほうがいろいろと楽ですし、”個人開発”っぽい見た目からも脱却できます。回避策：それっぽくなる配色を選ぶあまりデザインに凝ってないサイトでも、配色さえちゃんとしてれば、それっぽいサイトに見せることができます。色彩感覚に自信がなくても、配色ツールなどが沢山ありますので、それらに頼ればOKです。僕が普段からよくお世話になっているサイトを以下に紹介しておきます。その5. いつの間にかサイトがめちゃくちゃ遅くなっている遭遇確率　：★★★☆☆ どんな壁？：サービスをリリースしたが、自分で触ってもストレスがたまるほどに速度がめちゃくちゃ遅い解決策：とりあえず PageSpeed Insights で原因を探る PageSpeed Insights：https://developers.google.com/speed/pagespeed/insights/ ここでは、フロント側が原因なのかサーバー側が原因なのかが分かれば良いので、項目としては「サーバー応答時間」と全体の速度に着目すればOKです。もしサーバー側の速度が問題だと分かれば LB, APP, DBサーバー間のネットワーク環境の確認 nginxやApacheなどのサーバーソフトウェアの設定値等の確認 SQL文の見直し（N+1問題を引く起こすクエリはないかなど）などをメインに追っていき、問題箇所をひたすらチューニングしていきます。経験上、フロント側の速度は画像やファイル等のサイズを最適化するだけで大幅に改善するので基本的にはそのくらいで大丈夫かなと思います。ちなみにPageSpeed Insightsでの点数が高いからといって、ユーザーの体感速度も速いというわけでもないので、ある程度の点数が取れて問題なさそうだったら、特にこだわりとかがない限りそこでチューニングは打ち切って良いです。（サービスを作る目的が技術力向上である場合はまた変わってくる）その6. リリースしたけど誰にも使ってもらえない遭遇確率　：★★★★☆ どんな壁？：リリースまでたどり着いたが、だれにも使ってもらえない。そもそもサイトに訪問してくれない回避策：ターゲットとなるユーザーに直接アプローチを掛けるリリースしたけど誰にも使ってもらえない場合は、TwitterやFacebookでターゲットになりそうな人を探して直接アプローチを掛けます。アプローチの内容はフォロー、いいね、リプライ、DMなど様々ですがこれはターゲットの属性をみながら適切な方法を選びましょう。下手に身近な人に使ってもらおうとしても、そもそもその人がサービスのターゲットユーザーではない可能性が高いので注意が必要です。回避策：サービスを紹介できるサービスを使うインターネット上には自分が作ったWebサービスを紹介できるサービスが存在します。掲載したからといってドンとユーザーが来るわけではありませんが、基本的に無料で掲載できますので誰にも使ってもらえない場合は有効活用します。参考記事：個人でWebサービスを公開したときにやったことリストその7. コンテンツがないから人が集まらない or その逆遭遇確率　：★★★★☆ どんな壁？：サービスをリリースしたが、コンテンツがないため人が集まらず、人が集まらないためコンテンツも生まれない回避策：過疎っているようにみせない工夫をするたとえ内部の実情としては過疎っていたとしても、初めてサイトに足を運んだ人からは過疎っていないようにみせる工夫が必要です。過疎っているようにみせない工夫の例を以下に挙げておきます。サイトトップはサービスの紹介と登録・ログインの専用ページとする自分の手や周りの力を借りて初期コンテンツを投入するユーザーが投稿したコンテンツは日付を重視して扱わないはじめはツールとして提供して人が増えてきたらコミュニティの機能を増やすその8. リリースできたがサーバー代が高すぎる遭遇確率　：★★★☆☆ どんな壁？：サービスをリリースできたが、サーバー代が高くてやっていけない回避策：ひたすら無料プランを攻める誰もが真っ先に思いつくことではありますが、サーバー費用を徹底的に抑えたい方は、AWS、Azure、GCPなどで提供されている無料枠を使いつぶすという手があります。各クラウドサービスの無料枠については以下の記事で解説されているので気になる方はご参考ください。無課金にやさしいクラウド探し AWS vs Azure vs GCP 回避策：基本VPS + 一部クラウドな構成にする上の回避策と相反する内容ではありますが、便利だし技術的挑戦のために全部AWSで構成する！みたいなことをやるともれなく高額の請求がきます。クラウドは、企業が運営しているような大規模サービスではコスパが発揮されますが、小中規模のサービスの運用では逆にコスパが悪くなってしまう可能性が高いです。無料枠で収まらない可能性が高いのであれば、オールクラウドは少し考えた方が良いでしょう。個人的におすすめなサーバー構成としては、さくらやConoHaなどのVPSサービスに、AWSのS3やCloudfrontを併せて使うという方法です。無料枠を使わずとも1500円前後で1つのサービスが運用可能です。その9. リリース後のバズでサーバーがパンク遭遇確率　：★★☆☆☆ どんな壁？：リリースしたサービスが無事にバズったが、サーバーがパンクしサービスが利用できなくなる回避策：はじめから最低限スケール可能な構成にしておく L4でもL7でもどちらでも良いのでリリース前からロードバランサは噛ませておくと良いです。 ConoHaのL4ロードバランサだと月額1000円、自前で実装するL7ロードバランサだと月額600円程度で利用可能です。オートスケールまではしなくてもこうしとくだけで、リリース後のバズで負荷が掛かっても、サーバーをクローンさせて割り振るIPを追加すればいいだけなのでかなり安心です。あるとないとでは大違い。すぐに謝れる準備をしておく下で紹介するその10でも通じることですが、もし何かしらの原因でサービスが落ちた場合、できるだけ早く現状と予定を通知できるようにいざという時どう対応すればいいかをマニュアル化して残しておくとよいです。この方法については、れとるときゃりーさん（@retoruto_carry）の記事が参考になるのでぜひ読んでみてください b webサービスの本番サーバーをダウンさせてしまった時に爆速で土下座する方法🙇‍♂️🙇‍♂️💦💦 その10. DDoS攻撃を受けてサービスが瀕死状態になる遭遇確率　：★☆☆☆☆ どんな壁？：運用しているサービスがDDoSなどの外部攻撃を受けて瀕死状態になってしまう回避策：オリジンサーバーのIPを隠す以前、リリースしたてのサービスにDDoS攻撃があり、ロードバランサ、数台のAPPサーバー、DBサーバーが全てダウンしてしまうことがありました。その後、様々な人に助けれて解決したわけですが、結論からいうとCloudFlareやAWSのCloudFrontなどの負荷分散機能付きのCDNサービスを上段に噛ませてあげることで対策ができました。個人サービスにDDoS攻撃などが来ることは滅多にないので必ず対策すべきとまではいきませんが、Cloudflareなどは無料枠でも十分に利用することができるので、ひと手間かけて対策しとく分には損はないかなと思います。その11. リリース後のバズで夢を見るがその後地獄をみる遭遇確率　：★★★☆☆ どんな壁？：リリースしたサービスが無事にバズってユーザーが一気に流入したけど、ニ週間後には殆どがいなくなってしまった。（DDoSよりもなによりも一番これがメンタルやられる） ※ 実際に運営しているサービスのアクティブユーザーの推移これはサービス毎に原因が様々なので、以下抽象的な内容になっていますがご了承ください。バブルが弾けてもあきらめない特にコミュニティ系・CGM系のサービスで、リリース初期にバズったことで人がたくさん集まったがその後殆どいなくなる、なんてことを経験するともれなく精神がボロボロになります（上図でいう①から②）。少なくとも開発仲間がいればその辛さを分け合えますが、個人開発となるとそれはもう・・・。開発した本人からみても、コンセプトの段階から明らかにズレていたなどといった場合を除いて、②の状態が続いてもあきらめずにサービスの改善を続けましょう。解決策：1. 穴が開いたバケツを修繕する図中②の状態に陥ったらまずなぜ人が離脱していったかを考えます。人がいなくなったから直ぐにまた宣伝などして呼び込もうとせずに、サービスの根本的な部分から疑って、改善すべき部分を時には1から実装し直すなどして作り直していきましょう。解決策：2. 新規ユーザーの流入元を確保する完璧ではなくともサービスの改善が出来てきたら、次は新規ユーザーの流入元を確保するフェーズに入ります。ここで一番手っ取り早いのがSEO。サービスに関連するコンテンツを自分で追加するなりして地道に検索流入を増やしていきます。それと同時に他に改善すべきところはないかを少しずつ探り、随時修正していきましょう。後はひたすらこれの繰り返しです。その12. リソース不足で運用に手が回らない遭遇確率　：★★★☆☆ どんな壁？：開発と運用を全て一人でこなしているため、リソースが足りず、一部の運用やユーザー対応などに手が回らなくなってしまう解決策：無駄な作業は意識的に自動化していくサービスの機能追加や改善だけに手を取られていると、メンテナンスに掛かるコストが増大して最悪の場合サービスを閉鎖せざるを得ないところにまで陥ることもあります。サービスを個人で作り運用していく以上、使えるリソースは限られていますので、手動で行っている無駄な作業は意識的に自動化していきましょう。時には外部ツールに頼るのもありです。自動化できる作業の例をいくつかあげるとこんな感じでしょうか SSL証明書の定期更新お問い合わせやフィードバックがあった際の自動通知サーバーの監視・異常検知した際の通知サーバーのオートスケール機能 etc… # その13. 誰かが投稿してくれたかどうかが気になって仕方がない遭遇確率　：★★★☆☆ どんな壁？：CGM系のサービスを運用していると、「誰かが投稿してくれたかな？」などといったことが気になり何度もサイトを確認しにいってしまう。時間が溶ける。解決策：SlackやLINEを最大限活用するサービス上で何かイベントが起きる度にSlackやLINEに通知を送るようにします。それぞれAPIキー等を登録さえすれば1行2行のコードでPush通知を送れるので、スマホでも気軽に確認ができます。かなり便利です。以下はRailsでgemを使った場合のコード例になります。 Slackの場合 Gem slack-notifier を使用 notifier = Slack::Notifier.new('') notifier.ping('') LINEの場合 Gem line-bot-api を使用 message={ type: 'text', text: '' } response = client.push_message(user_id, mesage) その14. ある日突然検索流入が激減する遭遇確率：★★☆☆☆ どんな壁？：今までサービスにあった検索流入がある日突然なくなった。しかも、どのページへの流入がなぜなくなったかが全く分からない。回避策：日頃から検索順位を追っておくサービス内のコンテンツに関係する検索ワードは日頃から順位を追っておき、Googleのアルゴリズムアップデートの影響などをいち早く察知できる状態を整えておくと安心です。検索順位チェック専用のツール等も存在しているので、CGM系サービスの運営者さんとかは色々調べておくといいかもです。色々具体的に書きたいところではありますが、諸事情により、ここでは1日あたり100クエリを無料で利用できる Google Custom Search API を使うことをおすすめしておきます（...！）おわりに以上が個人開発をしてきて僕がぶつかった壁とその解決策まとめでした。一部抽象的になってしまった部分もありますが、個人開発をしている人、これからしたい人の参考に少しでもなれたなら嬉しいです！

#Qiita

0 notes