langs: ja en ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ko en en ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja de zh ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja en ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en en zh ja en ja en ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja en ja en ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ko en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja en ko en ja en ja ja fr en tr pt ja en en en fi ja ja es en en en it it en fr vi br en de en id th pt en en en fr en it eo br en uz es en it en fa en pt en en en en en fr en en en en en de en en en en en en en en hbs_lat en en en en ja en en en en en en it en en en en en en en en en en de en en en en en en en it en en en en en en en en en en en en en en en en en en en de en en en en en en en en en en en en en en en en en en en fr en en en en en en en en en de fr en hu en en en en es en en en en en en es en fr id en de en en en en en en en en en en en en en en en en en en de en en ja en ja ja en ja en fr cv ceb en en ja en en en en en en en en en it en en en en en en en en en en en en en en en en en en en de en en en en en en en en en en en en en en ru en en en en en es en id ja ja en th en it en zh it de en sl en cs nl la hy en id en en et en en en sl en en fr en en en en en nb nb en ceb en en hbs_lat en en et ar da en el en en en es en en te oc ja pl en nl en ca en en ja en en en en en en it af ja es en en it en en pl en pt fi en en en en es en it en eu en en hu en es en en en en en en en fi en en de nl en pl en de en en fr en en en en en en en en en en sv de nl hbs_lat sv cs en en fr fr en de hbs_lat en en en en en en en en en en en en en en en en en fr en fr fr en en en it en vi en en en id tr it la en en en en en sv en en de ru en en en da en en ja es en pl en es et hu en en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja zh ja ja zh ja ja ja ja ja ja ja ja ja ja ja de en en en ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja fr ja ja ja ja ja ja ja ja ja ja en ja ja fi en ja ja ja ja ja ja ja ja en en en

text:
Cloud OnAir は、Google Cloud の製品をわかりやすく解説し、最新の情報などをいち早く皆様にお伝えする Online LIVE 番組です。
今回は、7 月 24 日から 26 日(米国時間)までサンフランシスコで開催された Google Next ‘18 がテーマです。初日および 2 日目に発表された新製品など最新情報を、Cloud AI、IoT、Data Analysis、DevOps に分けて、Google Cloud カスタマーエンジニアが語ります。デモも交えた新機能紹介をお楽しみください。
Cloud AI : AI を簡単にそして高速に使うための製品
Cloud AutoML Vision、Cloud AutoML Natural Language、Cloud AutoML Translation
Cloud ML Engine での scikit-learn と XGBoost のサポートと学習とオンライン推論、Cloud TPU v3(第 3 世代 TPU のアルファ版)
IoT : ML と連携した IoT アプリの可能性を広げる製品
Google Cloud の強力な AI 機能をゲートウェイや接続されたデバイスまで拡張できる Cloud IoT Edge
TensorFlow Lite 機械学習モデルをエッジ側で実行することができる ASIC チップ「Edge TPU」
データ処理を高速化する  Cloud Composer 、Dataproc Autoscaling、Dataproc Custom Packages
Istio と App Engine のワークロードを可視化する Stackdriver Service Monitoring
7 月 26 日放送 : Google Cloud Next ’18 最新情報
[Cloud OnAir] Google Cloud Next '18 最新情報 2018年7月26日 放送 from Google Cloud Platform - Japan
Google Cloud Next’18 で発表された内容は、次の 3 つのブログ記事、Google Cloud Next ’18 初日の出来事、Google Cloud Next ’18 2 日目の出来事、Google Cloud Next ’18 3 日目の出来事でも詳しく解説しているので、ぜ日ご覧ください。
Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
ラベル: #GoogleNext18 , Cloud OnAir , Google Cloud
Cloud Services Platform 登場 : サービスの高度な運用基盤をクラウドとオンプレミスの両方で提供
そうした中、私たちは Cloud Services Platform のビジョンを皆さんと共有できることをうれしく思います。Cloud Services Platform は、スピードと信頼性を高め、セキュリティとガバナンスをより良く改善するとともに、Google Cloud Platform(GCP)とオンプレミスの両方で実行できるコードを一度のビルドで作成する統合サービス ファミリーです。このプラットフォームを導入すれば、現在もしくは将来の IT インフラストラクチャをどこにデプロイしても、クラウドのメリットを享受できるようになります。
Cloud Services Platform は、すべての IT リソースを統一的な開発、管理、制御のフレームワークに統合し、価値が低くセキュアでないタスクをオンプレミスと Google Cloud インフラストラクチャの両方で自動化します。Cloud Services Platform に関する今回の発表内容は次のとおりです。
サービス メッシュ : Istio 1.0(オープンソース)、Managed Istio、Apigee API Management for Istio のリリース
ハイブリッド コンピューティング : マルチクラスタ管理機能を持つ GKE On-Prem
ポリシーの徹底 : Kubernetes ワークロードを統制する GKE Policy Management
Ops ツール : Stackdriver Service Monitoring
サーバーレス コンピューティング : GKE サーバーレス アドオン、オープンソース サーバーレス フレームワークの Knative
「私たちは、オンプレミスとクラウドの両方でコンテナを統一的にデプロイし管理できるプラットフォームを必要としていました。Kubernetes が業界標準となりつつある中で、デプロイのリスクとコストを低減するために GCP 上の Kubernetes Engine を採用することは自然な流れでした。」
- Dinesh KESWANI 氏、HSBC の Global CTO
Cloud Services Platform は、密接な協力関係にある Cisco とともに開発し市場に投入してきたハイブリッド クラウド製品と技術的、アーキテクチャ的に足並みを揃えたものになっています。Google Cloud と Cisco が共同開発した Cisco Hybrid Cloud Platform for Google Cloud は 8 月に正式リリースされますが、すでに Kubernetes Engine との整合性が証明されており、そのままの状態で GCP に対応できます。
本記事では、Cloud Services Platform のさまざまな要素を紹介しながら、完全なハイブリッド クラウド インフラストラクチャの基盤をどのように築いているかを説明します。
私たちは昨年、受け身の IT 管理から先手を打つサービス運用へと転換を図る企業を支援するため、大きな布石を打ちました。スタックの上位層を管理してアプリケーションの認識と管理を可能にするという考えのもとに、複数のパートナー企業と共同開発したオープンソースのサービス メッシュ、Istio を発表したのです。Istio は、マイクロサービスを大々的に管理するのに必要なパワーをオペレーターに提供します。オープンソースの Istio は近くバージョン 1.0 へと移行し、本番環境にデプロイできるようになります。
そして今回、この Istio をベースとして、Kubernetes Engine クラスタ内のサービスを管理する Managed Istio をアルファ リリースしました。このマネージド サービスは Kubernetes Engine で利用可能な Istio ベースのサービス メッシュで、エンタープライズ サポートを備えています。Managed Istio は、次の 3 つの高度な機能を提供することで、プロアクティブなサービス運用への転換を加速させます。
認証を必要とするセキュアな通信 : Managed Istio は、エンドポイントのセグメント化と粒度の細かいポリシー設定、異常動作の検出とコンプライアンスの確保、デフォルトでの mTLS 使用によるトラフィックの暗号化などを提供します。
まだ開発初期の段階ですが、お客様の環境のスケーラビリティと可用性、管理のしやすさを大幅に引き上げるとともに、コンテナとマイクロサービスの利用を促進するための基盤テクノロジーとして、私たちは Istio と Managed Istio に大きな期待をかけています。
コンテナとマイクロサービスはアプリケーション管理の方法として間違いなく優れており、共通の Kubernetes 管理レイヤを設ければその実現は大幅に早まるはずです。それを可能にしたのが、私たちが 4 年前にリリースした Kubernetes から生まれた Kubernetes Engine です。マネージド サービスの Kubernetes Engine は数多くのテストを通じて飛躍的に成長しています。実際、Kubernetes Engine のコア時間は 2017 年に前年比 9 倍に達しました。
そしてこの Kubernetes Engine と同じものが、近くオンプレミス インフラストラクチャでも利用できるようになります。まもなくアルファ テストに入る GKE On-Prem は、どこでも好きな環境にデプロイできる Kubernetes です。GKE On-Prem は Google によって設定され、Kubernetes のインストールやアップグレードを容易にするとともに、GCP とオンプレミスの両方に次の機能を提供します。
ハイブリッド IAM(Identity and Access Management)
大規模なクラスタの管理では、適切なセキュリティ制御手段を用いて、セキュリティ ポリシーを簡単に管理、徹底できるようにすることが必要不可欠です。私たちは今回、Kubernetes の実行場所に関係なく一元的にクラスタを管理できるようにする GKE Policy Management を発表しました。
GKE Policy Management を導入すると、Kubernetes 管理者は唯一真正なポリシーを設定して、すべての対象クラスタに自動的に同期させることが可能になります。GKE Policy Management は、リポジトリに格納された定義済みのポリシーをサポートするほか、既存の Google Cloud IAM ポリシーを流用することでクラスタを容易に保護します。GKE Policy Management はまもなくアルファ リリースされる予定です。興味のある方はこちらからサインアップしてください。
Cloud Services Platform には、ワークロードのクラウドへの移行を単純化するだけでなく、サービス運用の改善を図るための基盤を築くテクノロジーが含まれています。インフラストラクチャからサービスを見るのではなく、サービスを中心に据えてインフラストラクチャを見るためのビューを提供するのです。今回発表した Stackdriver Service Monitoring は、次のような新しいビューを提供します。
SLO(サービス レベル目標)モニタリング : Google の SRE 担当者がGoogle サービスに対して実施しているのと同様の方法(お客様中心で疲労が少ない方法)でモニタリングとアラートを行います。
サービス ダッシュボード : 1 つのサービスに対するすべてのシグナルを 1 か所にまとめ、従来よりも簡単かつ迅速にデバッグできるようにし、平均修復時間(MTTR)の削減に貢献します。
Stackdriver Service Monitoring は、強固な Istio インフラストラクチャと App Engine で動作するワークロードを対象として設計されています。
マイクロサービスは、ワークロードをクラウドに移行するスピードを引き上げるうえでシンプルかつ魅力的な手段であり、規模の大きいクラウド戦略へと進むためのルートとして機能します。マイクロサービスのディスカバリ、接続、管理は Istio によって実現できますが、社内のグループ、パートナー、あるいは社外の開発者がこれらのマイクロサービスを必要とするようになると、マイクロサービスはあっという間に境界線を越えて API になります。
企業はマイクロサービスの管理とともに API の管理も必要とします。Apigee API Management for Istio は、API 管理をマイクロサービス スタックにネイティブに拡張し、Google Cloud の Apigee API 管理プラットフォームである Apigee Edge の堅牢な機能で Istio を補完します。Apigee Edge には、API の利用状況の表示、アクセスの提供、製品化、カタログ化、ディスカバリなどの機能に加え、開発者のためにスムーズなエクスペリエンスを作り出して API の利用を促進するデベロッパー ポータルが含まれています。
コンテナと Kubernetes がなければ、Google の社内で今行われていることはとても実現できません。システム運用のサービス セントリック ビューもこれと同じくらい重要です。Cloud Services Platform は、前述のコア機能に加えて、その他の新しい機能領域へのアクセスも提供します。
GKE サーバーレス アドオンを使用すれば、サーバーレス ワークロードを Kubernetes Engine にワンステップでデプロイして実行できます。ソースからコンテナを瞬時に生成し、コンテナ ベースのステートレス ワークロードの自動スケーリングやゼロへのスケールダウンさえ可能です。GKEサーバーレス アドオンの早期プレビューにはこちらから参加できます。
Knative(ケイネイティブと発音)は、GKE サーバーレス アドオンを支えているのと同じテクノロジーによるオープンソースのサーバーレス コンポーネントです。クラウドかオンプレミスかを問わず、Kubernetes 上で動作するサーバーレス アプリケーションの構築とデプロイに必要なビルディング ブロックを提供します。Knative を使用すれば、モダンでコンテナ ベースのクラウド ネイティブなアプリケーションを作成できます。
Cloud Services Platform の導入により、ワークロードがどこにあるかに関係なく、クラウドの可能性を最大限に引き出せるようになります。Cloud Services Platform とサーバーレス コンピューティングの関連について解説した記事もこちらにありますので、ぜひご覧ください。
*この投稿は米国時間 7 月 24 日、Technical Infrastructure の Senior Vice President である Urs Hölzle によって投稿されたもの(投稿はこちら)の抄訳です。
- By Urs Hölzle, Senior Vice President, Technical Infrastructure
株式会社LIFULL の導入事例:物件画像のカテゴリー分類を AutoML で自動化。数十秒かかっていた分類を自動化で 2 秒に
創業以来、IT と不動産を融合した「不動産テック(リーテック)」を推進する株式会社 LIFULL(ライフル)。常に先進的なテクノロジーを活用し、人々の暮らしや人生を満たす、安心・安全な住まい探しをサポートする付加価値の高いサービスを提供し続けています。同社で、人工知能(AI)や機械学習を活用した、より付加価値の高い次世代サービスの提供を推進する 3 名のキーパーソンに話を伺ってきました。
■ 利用している Google Cloud Platform サービス
Google Cloud AutoML Vision、Google Cloud Machine Learning Engine、Google App Engine、Google Cloud Endpoints、Google Cloud Storage
新 UX 開発部 AI 推進ユニット
掲載物件数ナンバーワン(*1)の不動産・住宅情報サイト「LIFULL HOME'S(ライフル ホームズ)」の運営を中核に、「世界一のライフデータベース&ソリューション・カンパニー」を目指す LIFULL。2014 年には世界最大級のアグリゲーションサイトを運営する Trovit 社を傘下に入れ、世界 57 か国で事業を展開してます。
そのほか、介護や地方創生、引っ越し、保険など、不動産・住宅情報とは異なる分野の事業にも積極的に参入。LIFULL HOME'S 事業本部 新 UX 開発部 デバイスソリューションユニット ユニット長の横山 明子さんは、「当社は、多くのサービスを自社開発しているので、最新の技術を取り入れやすい環境が整っています。今回、Cloud AutoML Vision(AutoML)の導入で、LIFULL HOME'S における利便性の向上を目指しました。」と話します。
最新技術の活用の一環として、AI や機械学習の活用を推進。2018 年 3 月には、おとり物件自動検出システムの刷新に機械学習を活用したほか、2018 年 5 月には、建物に AR 対応のスマートフォンのカメラをかざすだけで、物件の空室や売り物件を手軽に探せるサービス「かざして検索」をスタートしています。
(*1)出典:産経メディックス調査(2018 年 1 月 30 日)
しかし、不動産会社やデベロッパーの担当者は、複数の不動産・住宅情報サイトに物件情報を登録しなければならないため、物件の写真をアップロードするだけで手いっぱいで、画像のカテゴリーまで登録する余裕がなく、その多くがプルダウンの初期値である「その他」で登録されていました。そのため、LIFULL HOME'S で物件を探している利用者は、物件画像を利用した効率的な物件選びを行うことが困難でした。そこで 2015 年~2016 年ごろ、不正カテゴリー登録検出システムを開発し、カテゴリー登録が不正な物件画像を検出するための解析を行いました。
解析の結果について、LIFULL HOME'S 事業本部 新 UX 開発部 デバイスソリューションユニット 開発グループの衛藤 剛史さんは、「アップロードされた物件の画像を解析し、カテゴリーを自動的に分類できる機能が必要だと感じました」と語ります。そこで 2018 年 2 月より、AutoML の本格的な導入プロジェクトをスタート。2018 年 5 月に、AutoML を採用した物件画像の一括アップロード機能を公開しています。AutoML の採用を決めた理由を衛藤さんは、「Google が最先端の AI や機械学習に関する情報を持っていることや、AutoML が非常に高い精度で物件画像を分類できたことが理由です。また、Google Cloud Platform(GCP)上で、統合的に利用できることも採用を決めた理由の 1 つでした。」と話しています。
今回、GCP 上に構築されたシステムは、Google App Engine(GAE)で開発されたアプリケーションと AutoML を、Google Cloud Endpoints で管理された API で連携。AutoML は、Google Cloud Storage に登録されている物件画像を、Google Cloud Machine Learning Engine で解析し、GAE で開発されたアプリケーションに解析結果を戻す仕組みになっています。当初は、分類の性能に課題がありましたが、バスルームひとつでも、バスタブや給湯器など画像の特徴が複数あるため、バスルームのカテゴリーを細分化させる工夫により性能向上を実現しています。
AutoML の導入プロジェクトと同時に、 TensorFlow を使い、1 ~ 2 週間というごく短期間で検証用の独自モデルも開発。 AutoML で開発したモデルを比較すると、TensorFlow の評価指標(AUC)が 0.897 だったのに対し、AutoML の評価指標は 0.9559 という高い精度を実現しています。衛藤さんは、「TensorFlow で短期間に作成した独自モデルも悪くなかったのですが、AutoML の精度の高さを実感しました。専門家でなくても、簡単に AI の恩恵を受けることができます。また Cloud Endpoint は、セキリュティを自前で実装する必要がないので、開発を効率化できました。」と話します。
10 数枚の物件画像を登録する場合、カテゴリーを手作業で分類すると、入稿ツールを開いてから 40 ~ 50 秒かかりますが、AutoML の導入により 10~12 秒に短縮が可能。物件画像の登録の手間は確実に低減できます。画像分類だけに限れば、AutoML によるカテゴリーの自動分類は 2 ~ 3 秒で可能です。導入から約 1 か月検証した結果、「その他」の分類率は 2 %低減され、「その他」以外のカテゴリーは分類率が最大で 3.9% 改善されました。横山さんは、「今後、使い続けると、さらに効果が期待できます。」と話します。実際に利用した不動産やデベロッパーなどの担当者からは、「カテゴリーを一つひとつ選択する手間が省けて便利」や、「以前と比較して、画像入稿が格段に早くなった」というフィードバックも得られています。
物件情報 入稿ツール : 画像を一括でアップロードすると AutoML により自動で画像種別を分類
LIFULL HOME'S 事業本部 新 UX 開発部 AI 推進ユニット ユニット長の林 信宏さんは、「機械学習は参入障壁の高い分野でした。AutoML は、機械学習の専門的な知識がなくても、必要な項目を設定するだけで、精度の高いモデルを作成できます。操作性もよく、機械学習を活用するハードルを下げてくれます。今後も LIFULL HOME'S 全体で AI や機械学習を推進していきますが、Google の先進技術には期待しています」と話しています。
Cloud OnAir 番組レポート :Google Compute Engine に Deep Dive
Cloud OnAir は、Google Cloud の製品をわかりやすく解説し、最新の情報などをいち早く皆様にお伝えする Online LIVE 番組です。
今回は、「Google Compute Engine に Deep Dive! 基本から運用時のベストプラクティスまで」と題して、Google Compute Engine を詳しく学びます。
2012 年からサービスを開始している Google Compute Engine は仮想マシン(VM)を提供する 1 つの方法です。本番組では、コスト、パフォーマンス、運用の 3 つの観点から、Google Cloud Engine がどのようなものか、どのようなケースで利用するのが良いか、利用にあたっての注意点などを詳しく解説します。以下に番組のポイントをピックアップします。
割引の種類 : 課金は秒単位で、実際に使用した分しか料金はかかりません。継続利用割引と確約利用割引という 2 種類の割引があります。
マシンタイプ : 事前定義されたマシンタイプの中にニーズにあったものがない場合、仮想 CPU 数やメモリ量を自由に設定できます。これをカスタムマシンタイプと呼びます。カスタムマシンタイプでは、GPU もアタッチ可能です。
推奨サイズ : サーバスペックの推奨サイズを自動的に提示する機能です。
プリエンプティブル VM : 通常のインスタンスに比べて低価格で作成できるインスタンスです。最大 24 時間利用可能で、プリエンティブル VM には、GPU を追加することもできます。
安定したパフォーマンス
VM の起動時間 : 1VM あたり 20 秒から 40 秒と高速に起動することができます。クラスタサイズを増やしても起動時間は変わらず、1000VM を 1 分程度で立ち上げることができます。
永続ディスク : ストレージに関しては、高いパフォーマンスと信頼性、柔軟性に富んだサービスを提供します。永続ディスクは、標準のハードディスクと SSD を選択できます。さらに、より高いパフォーマンス要求に対応するため、ローカル SSD を利用することもできます。
ライブマイグレーション : ハードウェアやホスト OS などのメンテナンスが発生した際にインスタンスを稼働させたまま、同一ゾーン内の別ホストへ自動的に移行する機能です。Google Compute Engine には、ライブマイグレーションをシミュレーションする機能もあります。
仮想マシンのログイン管理 : IAM によりインスタンスへの SSH アクセスを管理することが可能です。
オートスケールの動作原理 : 負荷の増減に基づいてインスタンスを追加、削除する機能です。ポリシーを定義するだけで、自動的にスケールさせることができます。
仮想マシンのバージョンアップ : ブルーグリーンデプロイメント、カナリアリリースといったローリングアップデートをデモと合わせてご覧いただけます。
最後に、起動 / シャットダウンスクリプト(起動時の設定ファイルの取得、更新やシャットダウン時のログの退避、バッチ処理での活用)やメタデータサーバ(インスタンスに関する情報を管理)の特徴と典型的な使い方を紹介します。
7 月 19 日放送 : Google Compute Engine に Deep Dive
番組で説明した資料はこちらで公開しています。
[Cloud OnAir] Google Compute Engine に Deep Dive! 基本から運用時のベストプラクティスまで 2018年7月19日 放送 from Google Cloud Platform - Japan
Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
ラベル: Cloud OnAir , Google Cloud
エラー バジェットの使い過ぎを解消する : CRE が現場で学んだこと (後編)
2018年7月24日火曜日
CRE が現場で学んだこと』では、サービスのエラー バジェットと、サービスの信頼性目標、つまり SLO(サービス レベル目標)の遵守状況をエラー バジェットから把握することについて解説しました。エラー バジェットを使い過ぎる理由を把握できたら、次にやるべきことは問題を根本的に解決することです。
エラー バジェットの負債
クレジットカードを使い過ぎてしまい、その代金が毎月ごそっと口座から引き落とされた経験をお持ちではないでしょうか。うまく家計をやりくりするには、毎月の請求額を減らすよう負債をできるだけ支払っていくべきです。エラー バジェットについても同じことが言えます。
エラー バジェットの消費状況を分析し、消費率を高めている原因が特定できたら、新機能を担当している開発者の手を借りてでも、その原因に対処するための準備をしなくてはなりません。対処法としては、QA(品質保証)環境や試験セットを改善し、本番環境への移行前に多くのリリース エラーを見つけ出す方法もあれば、ロールアウトの自動化やモニタリングを改善し、不具合のあるリリースをより迅速に発見しロールバックする方法もあります。
こうしたアプローチの結果として、リリースの頻度が減ったり、リリースごとの変更点が減少してエラー バジェットへの影響が小さくなったりすることもあります。一時的にリリースのスピードを落とすのは、将来的に元のスピードで安全にリリースできるようにするためです。
下流での消費状況を把握する
もう 1 つ考慮すべきことがあります。エラー バジェットの使い過ぎの原因が開発者とは関係のないケースのときです。データセンターやクラウド プラットフォームで障害が発生した場合、開発者はなす術がありません。確かに、エンドユーザーはサービスの停止理由など気にかけないでしょうし、サービスの提供側もエンドユーザーにこれ以上迷惑はかけたくないでしょう。ただ、別の場所で発生した障害で自社の開発者を責めるのは無理があります。上述したように、エラー バジェットの消費状況を分析する際、この点は明確にしておきましょう。
次に、プラットフォームのオーナーに過去の(数値化された)信頼性状況を確認し、サービスの運用にあたって目標とする SLO とどう適合させるかを相談する必要があるかもしれません。その際、プラットフォーム側とサービス側の両方で変更が必要となることもあります。プラットフォームに特定の不具合が発生した場合に備えて、サービス側のシステムでそれを検知し、不具合に耐えられるようなシステムに変更するのです。プラットフォーム側でも検知機能を向上させれば、サービスに影響が出るような障害に迅速に対応してもらうことも可能になります。
プラットフォームが大幅に変更されるようなことは、実際はあまりありません。そのため、今後その障害にどう対応するかは決めておきましょう。障害を重大視するのであれば、影響を受けたクラウドのリージョンからサービスを自動的に他のリージョンにフェイルオーバーさせるオプションを実装(そして実行)するなど、回復力を高めるための対応が必要になります(これに関しては過去のブログ記事で扱っています)。
ソフトウェアのリリースに問題があるケース
分析の結果、エラー バジェットの使い過ぎの主な原因がソフトウェアのリリースだったというケースもあります。確かに、私たち Google の経験から言えば、バイナリのロールアウトは障害の最も大きな理由の 1 つです。この場合、たとえば事後分析は次のような文章から始まるでしょう。「ソフトウェアの新リリースをロールアウトしたら、ユーザーが喜ぶであろう となるはずだったのが、実際には となってしまい、ユーザーのブラウザでエラーが発生したり、猫の写真が表示できなかったり、1 分間にメールが 100 通戻ってきたりした。」
エラー バジェットをオーバーするような粗悪なリリースが連続しているときの模範的な対応は、新機能のリリースを凍結することです。これは最終手段と考えてよいでしょう。負債を減らす努力が十分な信頼性向上に結びついていないと認めることになるため、ユーザー エクスペリエンスを維持するには変更の頻度を下げることが求められるのです。リリースの凍結により、開発チームには時間や方向性が与えられ、頭を切り替えて信頼性向上に再度集中できるようになります。とはいえ、これはかなり思い切った方法です。
リリースの凍結を避けたい場合は以下のような方法もあります。
合意のもとで機能と信頼性のバランスを調整する : たとえば、いつも 2 週間分の仕事を割り振り、通常はそのうち機能面の開発に 95 %、事後分析への対応やその他の信頼性関連の仕事に 5 % 費やしているとします。SLO が遵守できていない間は、その割合を 50 % ずつにすると決めるのです。
サービスをオーバープロビジョニングする : たとえば、ほかのクラウド ゾーンやリージョンにレプリケートするための投資を増やしてみましょう。もしくは、サービスのレプリカを稼働させ、トラフィックの負荷が上昇しても対応できるようにします。ただしこれは、このアプローチがエラー バジェットの消費抑制に有効だと判断した場合のみ有効です。
リライアビリティ インシデントが発生したと申告する : 事後分析とエラー バジェットの使用状況を分析し、解決法を探る担当者を決めましょう。こうした解決法を最優先にすると事前に表明しておくことが重要です。
実際に新機能を凍結させる必要があるとしたら、いつまで凍結を続ければよいのでしょうか。一般的には、エラー バジェットの使い過ぎが改善され、同じことが起こらないと確信が持てるまでです。エラー バジェットの計算方法は主に 2 つです。固定された期間で計算する方法と(毎月 1 日~月末)、定期的な間隔で計算する方法です(過去 N 日)。
固定期間でエラー バジェットを計算する場合、エラー バジェットの使い過ぎへの対応は、バジェットをオーバーするタイミングによって決まります。たとえば初日にオーバーすると、その月はずっとリリースを凍結することになります。ただし 28 日目にオーバーしても、実際にリリースをやめる必要はないかもしれません。次のリリースは、エラー バジェットがリセットされた翌月になる可能性があるためです。お客様が月ごとの停止状況を気にしているのなら話は別ですが、これはユーザー エクスペリエンスを最適化するにあたってあまりいい方法とは言えません。
一方、30 日間隔でエラー バジェットを測定すると、可用性 99.9 % のサービスは N-30 の間隔で使用したエラー バジェット分を埋め合わせることになるため、20 分のオーバーとなったときは、20 分の借金分がなくなるまで待たなくてはなりません。つまり、N-29 日に 15 分のバジェットを消費し、N-28 日に 5 分のバジェットを消費した場合、残高をプラスの状態にするには、ほかに障害が起こらないと仮定しても 2 日間待つ必要があります。実際には、バッファーとしてエラー バジェットの 20 % 分が貯まるまで待てば、予期せぬ小規模な障害にも対応できるようになります。
この方法に従ったうえで、月間の全エラー バジェットを 1 日で使い切るような大規模障害が発生した場合は 1 か月間の凍結を余儀なくされますが、実際にはこのようなことは受け入れられないでしょう。ただ少なくとも、リリースのスピードを大幅に緩め、根本的原因の修復に時間を割く必要はあるでしょう(前述の「エラー バジェットの負債」の項を参照してください)。ほかにもアプローチはあります。『CRE が現場で学んだこと』シリーズの過去記事でリリースの停止について解説しており、そこでエスカレーション ポリシーの例を分析しています。
以上のように、定期的な間隔でのエラー バジェット測定は、障害が発生した日にちに応じて対応が異なるということもありません。できる限りこの方法を採用するようお勧めしますが、現在の監視ツールでこのようなデータを収集することは難しいかもしれません。
リリースの凍結による長期的なコスト
新機能のリリース凍結にもコストはかかります。最悪のケースとしては、開発者による新機能の開発が続いているにもかかわらず、それをユーザーにリリースすることはせず、結果として変更点が積み重なり、後でリリースを再開したときに次々と不具合が見つかるということがあります。
これは実際に起こっていることです。たとえば、ブラックフライデーやニューイヤーなどのイベントでサービスの新リリースを凍結すると、その翌週はバックアップしていた変更のすべてがユーザーに届けられることになり、サービスに不具合が発生して非常に忙しくなります。こうした状況を避けるには、凍結の影響を受けるチームに対して、この凍結が機能の開発ではなく信頼性の開発に注力する余裕を持つためのものであることを、再度強調しておくことが重要です。
また、すべてのリリースを凍結することが難しい場合もあるでしょう。カンファレンスなどの大規模なイベントを予定しているときは、直近のユーザー エクスペリエンスがどうであれ、特定の新機能を本番環境にプッシュしなくてはならないこともあります。そこで、このような場合は特効薬を投入することも検討してみましょう。製品管理チームは、重要な機能をデプロイするために、リリースの凍結を無効にできるという(非常に制限された)権利を持っています。特効薬をうまく使う方法としては、この権利の行使には高額な費用がかかるようにし、頻度も制限することですが、特効薬の投入は障害と見なされるべきであり、事後分析を実施してなぜこうなったのか、今後の発生リスクを抑えるにはどうすればよいのかを調べる必要があります。
エラー バジェットを自社(およびユーザー)のために利用する
サービスの信頼性向上に信念を持って取り組んでいるのであれば、エラー バジェットは非常に重要な概念となります。家計の予算と同様に、エラー バジェットは(サービスの所有者が)使うためにあるもので、使い過ぎた場合にどうするかは、実際に予算オーバーとなる前にサービスの利害関係者間で合意しておくことが必要です。
エラー バジェットの使い過ぎが判明したときは、信頼性改善に向けて開発時間を優先させる機能凍結が効果的な方法となるでしょう。ただし、使い過ぎたからといって、反射的にリリースを凍結することが常に適切な対応とは限りません。エラー バジェットがどこで使われたのかを見極め、使い過ぎの発生源を縮小し、財布の紐を緩めるのが適切かどうか考えてみましょう。一番重要な原則は、データに基づいて実施することです。
SRE(サイト信頼性エンジニアリング)についてより詳しく知りたい方は、7 月に米国サンフランシスコで開催される Next '18 にぜひご参加ください。SRE の原則をサービスのデプロイや管理に適用する方法について紹介します。
SLO のエスカレーション ポリシー : CRE が現場で学んだこと
可用性とどう向き合うべきか、それが問題だ : CRE が現場で学んだこと
*この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの(投稿はこちら)の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
ラベル: CRE , エラーバジェット
株式会社シグナルトークの導入事例:Google App Engine を駆使して少人数・低コストでのソーシャルゲーム開発・運用を実現
2018年7月23日月曜日
日々、多くの新作がリリースされ、厳しい競争が繰り広げられているソーシャルゲーム市場。この夏、その激戦区に、オンライン麻雀ゲームでその名を知られる株式会社シグナルトークが本格参戦します。今や、数十名~数百名の開発者が携わることも珍しくないという、ソーシャルゲーム開発ですが、シグナルトークの新作『ダンまつま!~ダンジョンで待ってます!~』の開発メンバーは何と 4 名+a。その少数精鋭での開発を可能にした Google Cloud Platform の活用法について聞いてきました。
■ 利用している Google Cloud Platform サービス
Google App Engine、Google BigQuery、Google Cloud Storage、Cloud Datastore など
プロデューサー 松井 聡弥 氏
プログラマー 佐藤 貴之 氏
■ 株式会社シグナルトーク
100 万以上の会員を持つ PC、スマートフォン向けオンライン麻雀ゲーム「Maru-Jan」の開発・運営を主軸に、ヘルスケアアプリや、ゲームアプリなどの開発・運営も行うゲーム開発会社。“クリエイターの理想郷” を作るをビジョンに掲げ、勤務体系や報酬制度など、クリエイターが働きやすい環境作りを追求している。2017 年、リクナビNEXT が主催する働き方改革アワード「第 3 回グッド・アクション」受賞。従業員数は約 40 名(2018 年 5 月時点)。
Google App Engine の高機能・柔軟性が開発のリスクを大幅に低減
『ダンまつま!~ダンジョンで待ってます!~(以下、ダンまつま!)』は、シグナルトーク初となる、企画から開発までを自社で行ったオリジナル ソーシャルゲーム。ゲームジャンルとしては、いわゆる「タワーディフェンス型」で、プレイヤーは、異世界に “転生” した魔王となって、ダンジョンに攻め込んでくる冒険者を、モンスターや罠などを駆使して撃退します。その差別化ポイントは「プチダークファンタジー」というコンセプト。ちょっとユルい、“日常系” な世界観が、殺伐とした雰囲気を和らげ、プレイヤーの間口を大きく広げる一助となっているそうです。人気声優を起用したかわいらしいキャラクターや、3DCG を駆使した迫力あるゲーム画面など、近年のソーシャルゲームに必須とされる要素もしっかり押さえています。
しかし、どうして麻雀ゲームで一定以上の成功を収めているシグナルトークが、未踏のソーシャルゲーム市場に挑戦することになったのでしょうか?その背景を本作のプロデューサーにして、自らゲームシステム、シナリオ、世界観設定なども手掛ける松井 聡弥さんに聞いてみました。
「シグナルトークにはラボという仕組みがあって、社員であれば誰でも新しい企画を提案することができます。『ダンまつま!』は、その仕組みを使ってスタートした新プロジェクト。会社として麻雀ゲーム以外の事業を開拓していきたいという狙いがあったのはもちろんですが、私自身、ゲームが大好きで、いつかこうしたものを手掛けてみたいと思っていたんです。」(松井さん)
企画が承認されたのは 2017 年初頭、そして実際にプロジェクトが動き出したのはその年の 5 月頃でした。期待のプロジェクトではあるものの、採算性などが全く読めない新規事業であったため、開発チーム構成は可能な限り少数精鋭に。クライアントサイドのプログラマーが 1 名、デザイナーが 1 名、そしてサーバーサイドを佐藤さんが兼任というかたちでスタートすることになりました(ただし、キャラクターデザインおよび UI/UX 開発は外注。また、今年 4 月にはディレクターが 1 名追加されています)。
「開発チームも小規模で、何よりノウハウが全くなかったため、どれくらいのユーザーに遊んでいただけるのか、どういった負荷がかかるのかが読めません。フルマネージドかつオートスケールが優秀な Google App Engine(GAE)の採用は自然な流れでした。現在、主力の麻雀ゲームは全てオンプレ環境で運用しているのですが、それは開始当時にそれしか選択肢がなかったからで、今、積極的にやりたいことでありません。ですから、パブリッククラウドを使うことに抵抗はありませんでした。もちろん、他のプラットフォームも検討しましたが、どれもある程度、面倒を見てあげなければならず、フルマネージドの GCP ほど理想的ではありませんでした。そのほか、BigQuery の存在も決定打になりましたね。統計でも楽をしたかったので(笑)。」(佐藤さん)
ちなみに、オートスケールについてはスケールアウトはもちろん、効率的にスケールインすることも大事なのだそうです。PC 向けゲームと比べて、時間帯によって人の増減が激しいスマートフォン向けゲームでは、使われていない時間帯に費用を抑えられるというのはコスト対策的にも非常に重要。ピークに合わせて環境を構築せねばならないオンプレ環境はそういう意味でも現実的ではなかったと言います。
「なお、開発言語には Go を利用しているのですが、これはスピンアップが非常に速いのが魅力。100 ミリ秒にも満たないんじゃないでしょうか……。結果として、必要な時だけインスタンスを起動する、サーバーレスな運用が可能になります。そうすると運用コストをギリギリまで削減できますから、どんなに好調でもいつかはやってくるサービス終了を先に延ばすことができるのではないかと考えています。わずかでも楽しんでいるお客さんがいらっしゃるならクローズしたくないという気持ちは、ゲーム開発者なら誰もが持っていますが、GCP ならそれができるのではないかな、と。今、考えることではないですけどね(笑)」(佐藤さん)
『ダンまつま!~ダンジョンで待ってます!~』システム構成図
低コストで安定した開発環境もスムーズな制作に貢献
プロジェクトが実際に動き出したのは昨年 5 月頃でしたが、当然ながら、当初はクライアントサイドの開発が先行、サーバーサイドの開発がスタートしたのは、クライアントサイドがある程度作り込まれ、仕様の定まった 12 月頃でした。
「ある程度動く状態になったのが 2~3 月くらい。そこから作り込んでいき、B 版と言える状態になったのは 6 月くらいですね。開発をしていて、感心したのが GAE のログ周りが充実していたこと。本番環境でのログがすごく見やすくて、追いやすいんです。エラーが出ていたら、クリックするだけでソースまで開いてくれるのがありがたかったです。また、ローカル側のサーバーも安定して動くうえ、本番環境で動作が異なるということもほとんどなかったのも開発効率を高めてくれました。それと、GCP の管理用スマホアプリのエラー通知機能も重宝しています。将来的には Stackdriver の導入も検討しているのですが、とりあえずはこれで充分かな、と。本運用でも役に立ってくれそうです。」(佐藤さん)
「プロデューサーとしては、サーバーサイドの開発がスムーズに進んでくれたことに、とても助けられました。一応、スケジュールを立てていたものの、正直、もっとかかるのではないかなと思っていました。当初は、途中でサーバーサイドのスタッフを増やす必要があると考えていたのですが、その必要がなくここまで来ることができ、結果としてコストも抑えることができています。また、サーバーの利用料金についても、開発時点のアクセスでは数千円/月レベル。無料枠をまだ使い切れていないという状況です。一番最初の企画段階ではサーバー費用を 30 万円/月と見積もっていたので、驚きですね。その分の費用をキャラクターのイラストなどに回せたのは良かったです。」(松井さん)
取材時点(6 月中旬)では、7 月のリリースに向けて、最終調整中だった『ダンまつま!』。先日行われた負荷テストでは、「サーバーより先に、クライアント側の方が悲鳴を上げてしまいました(笑)。」(佐藤さん)とのこと。
また、こうした手応えを踏まえ、別途開発中の別プロジェクトでも GCP の利用が始まっているそうです。
「具体的なことはまだお話できないのですが、麻雀関係のプロジェクトで GCP を利用することが決まっています。GCP には GAE 以外にも多くのプロダクトがあるので、仮に GAE でできないことがあっても GKE(Kubernetes Engine)で実現できるなど、柔軟に対応できるのがいいところ。また、個人的には、Cloud Spanner や、Cloud Memorystore、Google Cloud Machine Learning なども使ってみたいですね。」(佐藤さん)
株式会社シグナルトークの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。
ラベル: App Engine , GCP導入事例
Google Cloud Next '18 in Tokyo スケジュール公開、セッション登録開始
2018年7月19日木曜日
9 月 19 日 (水) 、20 日 (木) の 2 日間にわたって開催する Google Cloud Next '18 in Tokyo まで 2 か月となりました。本日より、イベントサイトに各セッションのスピーカーや詳細スケジュールを公開し、セッション登録をしていただけるようになりました。
イベント申し込み & セッション登録
1 日目の基調講演は、“Building a Cloud for Everyone” をテーマに、Google Cloud CEO のダイアン グリーン、グローバルアライアンス & インダストリプラットフォーム部門 プレジデントのタリク シャウカットをはじめ多数のスピーカーが登壇し、最新のクラウドテクノロジーや “ AI for everyone “ にまつわるトピックをお届けします。さらに、企業の経営者の方をお招きし、ビジネスやプロジェクトの根幹を支える Google Cloud 活用術についてお話いただきます。
2 日目の基調講演は、“Bringing the Cloud to You” をテーマに、Google Cloud Apps 部門 バイス プレジデントのプラバッカー ラガバンが登壇。G Suite の活用で進化する働き方について、実際に G Suite を導入されている企業の経営者の方をお迎えしてご紹介します。さらに、昨今注目を浴びるサーバーレスやオープンハイブリッドなどのテクノロジーを深掘りするとともに、今月サンフランシスコで開催する Next SFO で発表する最新テクノロジーのハイライトをご覧に入れます。
2 日間にわたり、午後は興味やレベルに合わせて選べる、130 を超えるブレイクアウト セッションをご用意しています。 セッションを選定いただく際は、カテゴリーやレベルでフィルタリングしてご自身に合ったものをセレクトいただけるようになっています。Next SFO に登壇するスピーカーも多数来日するとともに、日本オリジナルのセッション、ハンズオンラボ、GCP トレーニングも予定しています。ぜひこの機会に、Google Cloud のスペシャリストが企画したコンテンツを体感いただければと思います。
また、Google Cloud Expo では、最新のクラウド技術を体験できるデモブースや、独自のサービスをご紹介するスポンサーブースをご用意しています。さらに、2 日目の夜には ネットワーキングパーティーとして、“ Next '18 in Tokyo Night ” を企画しておりますので、ぜひふるってご参加ください。
人気セッションは早期の満席が予想されますので、まずはイベントにお申込みいただき、ご希望のセッションへのご登録をお願いたします。皆さまのご参加をお待ちしております。
イベント申し込み & セッション登録
イベント名: Google Cloud Next '18 in Tokyo
公式ハッシュタグ: #GoogleNext18
日  程: 2018 年 9 月 19 日(水)・20 日(木)
開  場: 8:30 (予定)
基調講演: 9:30 〜 11:30 (予定)
セッション: 12:00 〜 19:20
ザ・プリンス パークタワー東京 〒105-8563 東京都港区芝公園 4 - 8 - 1
東京プリンスホテル 〒105-8560 東京都港区芝公園 3 丁目 3 - 1
Google Cloud Next Tokyo '18 運営事務局
googlecloud-next18-tokyo@google.com
本カンファレンスは、各種 Google Cloud 関連製品サービスの導入を検討中のエンドユーザー企業、団体、教育機関、政府自治体向けのイベントになります。導入を検討されていない方には、ご登録いただいてもご受講いただけない場合もございます。
十分な座席数をご用意しておりますが、定員を超えた場合にはエンドユーザー企業様優先の抽選とさせていただきます。
ご不明な点は、こちらの FAQ をご確認ください。
ラベル: #GoogleNext18 , Google Cloud Next '18 in Tokyo
エラー バジェットの使い過ぎが意味するもの : CRE が現場で学んだこと
2018年7月18日水曜日
CRE が現場で学んだこと』シリーズでは、これまでも Google の CRE(顧客信頼性エンジニアリング)チームによる SLO(サービス レベル目標)の記事を掲載してきました。SLO とは、サービスが満たすべき信頼性の目標をエンドユーザーの視点から定めたものです。
SLO では特定の期間内にどの程度サービスのダウンタイムを許容するかを指定します。たとえば 99.9 % の可用性が求められるサービスの場合、30 日間における許容ダウンタイムは 43 分です。この時間がエラー バジェットとなります。家計の予算と同様に、エラー バジェットは、予算オーバーにならない限り 30 日間に利用してもよいとされるものです。
日々の運用での積み重ねや、大規模障害によってエラー バジェットを使いきってしまった場合、サービスを使用するユーザーは困難な状況に置かれることになるため、何とか対処しなくてはなりません。
では、一体どうすればよいのでしょうか。今回の記事では、エラー バジェットを再調整する必要があるかどうかを判断するときに考慮すべき点について説明します。
何にエラー バジェットを費やしているか
SLO は、対応する SLI(サービス レベル指標)のターゲット値となります。SLI はエンドユーザー エクスペリエンスの重要な部分の測定値です。先ほど例として挙げた、99.9 % の可用性が求められるシステムの SLI は、「すべての 20x および 50x の HTTP レスポンスのうち、成功した HTTP レスポンス(200)の割合」となります。エラー バジェットの使用量は、サービスが SLO のすべてを達成できなかった測定期間の割合で計算します。これは、SLI の粒度や正確さに応じて、1 分ごとや 1 時間ごと、あるいは 1 日ごとに計算することも可能です。
日々のエラー バジェットを分析するには、測定期間中に使用したエラー バジェットについて、その主な理由がどこにあるのかを明らかにする必要があります。
ほとんどのエラーがバイナリ リリースの際に発生している場合は、リリースの頻度を控えたり、エラーを起こりにくくしたり、エラーが発生しても影響があまり出ないようにしたりといった対策が必要です。そうしないと、エラー バジェット内に収めることは難しいでしょう。
断続的なアプリケーション障害によってずっと同じようなエラーが発生し、それがエラー バジェットの大半を占めている場合は、アプリケーションに根本的な欠陥があるということです。ログを掘り下げて問題のクエリを探し、エンジニアと協力して根本的原因を特定したうえで、直接対処するか、もしくは次のプロジェクトの計画サイクルで修正しなくてはなりません。
“configuration pushes” や過度の負荷、“queries-of-death” が原因でサービスの大半が何分間にもわたって停止するような大規模アプリケーション障害が発生し、そこにエラー バジェットの大半が費やされている場合は、効果的な事後分析を実施して根本的原因を突き止め、障害を緩和させるべきでしょう。開発エンジニアの力を借りて、事後分析で優先順位トップとされた事項に対応する必要があります。したがって、機能の開発やリリースはおのずと後回しになります(これについては別の記事で詳しく説明します)。
クリティカルなバックエンドやコンピューティング プラットフォームのような制御対象以外との依存関係によって多くのエラー バジェットが消費されている場合は、その依存関係を見直すか、プラットフォームのオーナーと直接交渉し、SLI を示したうえで、サービスの信頼性を向上させる方法や予期される障害モードへの耐性を高める方法について話し合ってみましょう。
いずれのケースでも、問題に十分対処できたかどうかを客観的に測定することになります。以前は落ち込んでいた状況で SLI が高い状態を保つことが求められるのです。
シグナルを正しく査定しているか
ほかにも検討すべきことがあります。障害がユーザーの真の悩みを反映しているかどうかです。まとまった量のエラー バジェットを一気に使ってしまうような大規模障害が発生しても、そのことをユーザーはあまり気にしていないと確信が持てる場合は、開発業務やアーキテクチャを変更する必要はないかもしれません。とはいえ、何らかの修正は必要でしょう。新たに SLO の目標レベルを下げるか、ユーザー エクスペリエンスをより反映した別の SLI を検討するべきです。
ユーザー エクスペリエンスが低下してもユーザーは耐えられるか
99.9 % の可用性(1 か月あたり 43 分のエラー バジェット)でサービスを提供しようと努めてはいるものの、実際はその範囲内に常に収まらず、毎月 50~60 分のエラー バジェットを費やしているとします。これは実際、どの程度重要なことでしょうか。
サイト上での滞在時間や購入率、サポート チケットの発行数、さらには直接測定したユーザーの幸福度など、顧客満足度を測るビジネス インテリジェンスの手段はさまざまです。その統計を SLI と対比させて評価してみましょう。
エラー バジェットが超過した期間とユーザー満足度が下がった時期に関連性はありますか? 関連性があるとしたら、その相関関数はどうなっていますか? エラー バジェットが 50 % オーバーしたときの顧客収益が 1 % 減少しているのであれば、目標値達成に向けて可用性を高めようとエンジニアの労力をつぎ込むよりは、SLO を調整して可用性 99.5 % を確保するほうがよいと考えるかもしれません。
ここで重要なのは、SLO の目標値を決める際に使用するデータを入手し、文書化しておくことです。単に「ユーザーが気にしないから」という理由でエラー バジェットを 50 % 増やすような罠に陥ることがないようにしましょう。ユーザーの満足度/支出と、SLO の定義における信頼性との妥協点を明確にする必要があります。SLO の仕様は、単に数字や指標名があればよいというわけではありません。SLO のターゲットを決めるにあたっては、利用したロジックやデータが何なのかも示す必要があるのです。
ユーザー エクスペリエンスが明確でないケース
お客様が常に正しいというのは真実かもしれませんが、もしサービスのユーザーが社内にいる場合はどうでしょうか。一部のケースでは、常にエラー バジェットをオーバーしていても、ソフトウェアを構築しリリースを続けることが会社の利益のためになることもあるでしょう。エラー バジェットを使うことで従業員には迷惑をかけるかもしれませんが、ソフトウェアの新バージョンをリリースできないことのほうがユーザーに不便をかけることになり、企業にとっては大きなコスト増につながるかもしれないのです。
これは、ソフトウェアのユーザーが必要だと考えているもの(今回のサービスの例で言えば 99.9 % の可用性目標)と、ソフトウェア開発の予算を握っている幹部がユーザーに我慢を強いるべきだと考えているものとの間にギャップがある場合に起こる可能性があります。
以上で、エラー バジェットが何を伝えたいのかを理解できたのではないでしょうか。この記事のパート 2 では、うまくバランスを保つ方法について考えます。
SRE(サイト信頼性エンジニアリング)についてより詳しく知りたい方は、7 月 に US サンフランシスコで開催される Next '18 にぜひご参加ください。SRE の原則をサービスのデプロイや管理に適用する方法について紹介します。
優れた SLO を策定するには : CRE が現場で学んだこと
SLO 違反への対処 : CRE が現場で学んだこと
* この投稿は米国時間 6 月 28 日、Adrian Hilton、Alec Warner、および Alex Bramley によって投稿されたもの(投稿はこちら)の抄訳です。
- By Adrian Hilton, Alec Warner and Alex Bramley
ラベル: CRE , SLO , エラーバジェット
Cloud OnAir 番組レポート :GCP 活用事例紹介 - 株式会社リクルートライフスタイル
2018年7月17日火曜日
Cloud OnAir は、Google Cloud の製品をわかりやすく解説し、最新の情報などをいち早く皆様にお伝えする Online LIVE 番組です。2018 年 7 月から 9 月は、「Developer の方必見、夏の特別夏期講習」と題してお送りします。Google Cloud クラウド カスタマーエンジニアによるGoogle Cloud Plarform(GCP)の解説をはじめ、Google Cloud 最大のイベント「Google Cloud Next '18」の最新情報もいち早くお届けします。
さて、今回は、GCP 活用事例をテーマに、株式会社リクルートライフスタイルの前田周輝さんと堀澤健太さんをお招きし、GCP 活用にあたって、その背景、GCP 導入時の状況、導入後の効果などを具体的にお話していただきました。
どんな課題があったのか?
サービス開発の速度・質・規模の大幅な改革が求められる中で、リクルートライフスタイル様では、People/Process/Technology の観点からさまざまな取り組みを推進しています。
People に関しては、新チーム CET(Capture EveryThing)を 2015 年に発足し、データ分析、A/B Testing、データ拡張、リサーチを、ビジネス担当、技術担当、研究開発担当が一体となって行う体制を整えています。また、Process の観点からは、データプロダクトのライフサイクルを策定し、クラウド活用を前提とした開発基盤やプロセスを整備しています。そして、Technology の観点からは、「作る」から「使う」という方針のもと、従来のオンプレミスからクラウド化を積極的に推進してきました。開発者コミュニティにも積極的に参加し、有意義な情報交換をしているとのことです。
BigQuery、Kubernetes Engine、Bigtable によるクラウド化による効果のひとつが「データ活用プロセスの大幅な短縮」。 レコメンドの A/B Testing の例では、従来のオンプレミス環境で 3 日あまりかかっていた作業がわずか 20 分まで短縮できたと言います。
番組中では、80 億行ものテーブルを使って実際に加工・分析する様子をデモンストレーションしており、また、じゃらん net におけるレコメンド機能の実現において、どのような効果が得られたかを解説いただいています。
CET のアーキテクチャ
番組の後半では、データ活用基盤である CET がどのようなサービスから構成されているのか、アーキテクチャの詳細を紹介していただきました。ログ収集、機械学習バッチ処理、ストリームデータ処理、分析結果や機械学習の予測結果などの API 提供を実現する CET の構成を詳しく知ることができます。
リクルートライフスタイル様が、なぜ GCP を選択したのかも要所要所で語っていただいていますので、ぜひご覧ください。
7 月 12 日放送 : リクルートライフスタイル様の GCP 活用事例
番組で説明した資料はこちらで公開しています。
[Cloud OnAir] お客様事例紹介 リクルートライフスタイルにおける デジタルトランスフォーメーションとクラウド活用 2018年7月12日 放送 from Google Cloud Platform - Japan
次回(7 月 19 日(木))は、「Google Compute Engine に Deep Dive!基本から運用時のベストプラクティスまで」がテーマです。Google Compute Engine で仮想マシンのバージョンアップ・負荷分散をどのように行うかをご説明します。ぜひご覧ください。
Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
第 5 回 INEVITABLE ja night を開催します
2018年7月17日火曜日
Google Cloud に代表されるクラウド技術の進化が引き起こすその先の世界を、機械学習、VR / AR、IoT などの領域で活躍されているスタートアップの方々と一緒に議論するイベント「INEVITABLE ja night」。
今回のテーマは「最新技術で変わる、エンタメ、スポーツ、ライフスタイルビジネスの不可避な未来」です。モバイルデバイスの進化や AR などのエッジなテクノロジーがますます身近となり、エンターテイメントや日常生活にも浸透してきています。これは同時に、この分野でのテクノロジー提供者やビジネスにも大きな変化が起きることを意味しています。
そこで、「エンターテインメント×テクノロジー=エンターテックはカルチャーを創る」をビジョンにさまざまな事業に参画しているエンターテック・アクセラレーターの鈴木貴歩さんをメインゲストに迎え、South by Southwest(SXSW)などで見られる世界の潮流や事例を踏まえ、今起きている変革と今後の不可避な流れについて議論していきます。
講演会後には恒例の交流会も行います。参加者様同士の交流はもちろん、日頃の業務の課題や悩みについても、ご相談/共有いただける良い機会となります。
AR や AI サービス事業の企画、関連するシステム構築に関心のある方々のご参加をお待ちしています。
イベント名 : INEVITABLE ja night - “インターネットの次にくるもの”
第 5 回 最新技術で変わる、エンタメ、スポーツ、ライフスタイルビジネスの不可避な未来
日程 : 2018 年 8 月 2 日(木) 19:00 〜 21:00(開場 18:30 より)
会場 : グーグル合同会社
ハッシュタグ : #inevitableja
INEVITABLE 対談「エンターテックを実現するテクノロジーとプレイヤー」
スピーカー : 鈴木 貴歩 氏  (パレードオール株式会社 代表取締役 / エンターテック・アクセラレーター 氏)
聞き手: 小島 英揮 氏(Still Day One合同会社 代表社員 パラレルマーケター・エバンジェリスト)
Google テクノロジーアップデート
スピーカー: 松田 白朗(グーグル合同会社 デベロッパー アドボケート)
講演後は講師や参加者の皆さんとの交流や情報交換をお楽しみください。
参加を希望される方は、お申し込みサイトをご覧ください。
皆様のご参加をお待ちしております。
■■■ INEVITABLE TV のご案内 ■■■
イベントでは取り上げることができなかったこと、語り尽くせなかったことを中心に、「インターネットの次に来るもの」に関連する話題を深く掘り下げていく番組「INEVITABLE TV」ももぜひご覧ください。
TPU が拓く AI 活用の近未来(グーグル合同会社 佐藤 一憲)
VUI の普及と進化の方向性 (ゲスト : 岩佐 琢磨 氏)
クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション(前編)
2018年7月6日金曜日
編集部注 : 今回の記事は、数年前に SRE(サイト信頼性エンジニアリング)の本を出した(本当に!)Google エキスパート チームが執筆してくれました。実際に手を動かして学ぶ同書の姉妹書『The Site Reliability Workbook』も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウド コンピューティング時代のトラブルシューティングについて取り上げます。今回は 2 回連載の前編です。本稿を読み終えたら、クラウド プロバイダーとのコミュニケーション方法をテーマにした後編もぜひご覧ください。
技術的な問題を効果的に解決するためには、運や経験に頼るのではなく、系統的なアプローチが必要です。書籍『Site Reliability Engineering』の中でも述べたように、トラブルシューティングは学習できるスキルです。
しかしながら、クラウド インフラストラクチャ上でシステムやサービスを実行するようになって、あなたや運用チームはどう変わりましたか? ウェブサイトやアプリがどこで実行されているかにかかわらず、サイトが落ちたときに呼び出しがかかり、問題を解決し、疑問を解明しなければならないというプレッシャーにさらされるのは、依然としてあなたではないですか?
クラウドは、IT チームが旧来のシステムから移行しつつある新しい仕事の形です。システムがオンプレミスに存在したときは、システムのあらゆる側面を見てコントロールすることができました。しかし、オフサイトにあるクラウド ベースのインフラストラクチャに依拠するようになると、見ることで理解できる部分は限られてきます。それは、システムやプロセスがいかに一流で、あなたがいかに優秀なトラブルシューターであっても同じです。通常、クラウド プロバイダー システムの中身は見られる部分が限られています。
難しいのは純粋なデバッグだけではありません。クラウド プロバイダーとうまくコミュニケーションを取る必要があるのです。プロバイダーのサポート プロセスやエンジニアと関わりを持ち、問題がどこにあるかを協力して突き止め、できる限り早く問題を解決しなければなりません。これは、IT チームが新しいスキルを獲得し、クラウド ベースの技術モデルに適応するための格好のチャンスでもあります。
正しいクラウド トラブルシューティングは間違いなく可能です。重要なのは、クラウド プロバイダーを選ぶときに、彼らが問題発生時にどのように協力してくれるかをきちんと見極めることです。実際にプロバイダーと付き合い始めると、問題の伝え方や解決までのスピードに関して、あなたが思う以上にあなたは大きな役割を果たします。
私たちは、SRE モデルのアクショナブルな改善をヒントに、クラウド プロバイダーとの協力のもとで行う、より効果的で効率的なトラブルシューティングを提案したいと思います(トラブルシューティング プロセスを通じたクラウド プロバイダーとのコミュニケーションの方法については後編をご覧ください)。
クラウド プロバイダーのサポート ワークフローを把握する
問題は避けがたく発生します。したがって、ここでの目標は、問題が実際に発生したときに、プロバイダーに対して情報を適切に提供する最善の方法を見つけ出すことです。インフラストラクチャ向けにおそらく複数のクラウド プロバイダーを利用していることを考慮すると、まずはここから着手するのがうまいやり方です。通常、クラウド プロバイダーのサポート担当とのやり取りは、マイグレーションに関連した質疑応答から始まり、本番環境のインテグレーション、本番環境で生じた問題のトラブルシューティングへと進んでいきます。
頭に入れておきたいのは、顧客とのやり取りについての考え方がプロバイダーごとに異なるということです。たとえば、顧客に大きな自由度を与える代わりに直接的なサポートをあまり提供しないプロバイダーもあります。そのようなプロバイダーは、顧客自身が Stack Overflow などのオンラインフォーラムから答えを見つけるべきだと考えています。逆に、顧客と密接な関係を持ち、協力してトラブルシューティングにあたることを強調するプロバイダーもあります。
トラフィックをクラウドで本格的に処理するつもりなら、必ず済ませておかなければならない宿題があります。クラウド プロバイダーの営業担当者、プロジェクト マネージャー、サポート エンジニアと話をすることです。そして、プロバイダーがサポートにどのように取り組んでいるか、感触をつかんでおきましょう。次のような質問をしてみてください。
サポートに対する典型的なイシュー レポートのライフサイクルはどうなっているか?
問題が複雑もしくは重大な場合の社内のエスカレーション プロセスはどうなっているか?
の社内サービス レベル目標(SLO)はあるか? ある場合、その内容はどうなっているか?
プレミアム サポートとしてどのようなタイプのものを利用できるのか?
このステップは、クラウド プロバイダーの巨大なブラックボックスが関係している問題のトラブルシューティングにまつわる不満を軽減するうえで不可欠です。
クラウド プロバイダーのサポート担当との効率的なコミュニケーション
プロバイダーのサポート ワークフローがどのようなものなのか、その感じがつかめれば最良の情報伝達方法がわかります。その問題についてなぜ言及するのかを含め、プロバイダーのサポート チームに完璧なイシュー レポートを送るときに役立つベスト プラクティスがあります。報告の 80 % で役に立つ詳細情報の 20 % を知らせるという 80/20 ルールに従うのです。イシュー トラッカー、ユーザー グループ、フォーラムなどにバグ レポートを送る際にも同じ原則が当てはまります。
クラウド プロバイダーとのコミュニケーションを図るにあたっては、その方針に明確性が含まれていなければなりません。適切なレベルの技術的詳細を示し、望むことを明確に伝えることが大切です。
常識だと思われるかもしれませんが、イシュー レポートに基本情報を含めることはきわめて重要です。これらの詳細を書き漏らすと、解決の遅れや不満の残る対応の原因になります。
効果的なトラブルシューティングは、時刻、製品、位置、具体的な識別子から始まります。
イシュー レポートへの時刻の記載例を見てみましょう。
太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から 5 分後まで~が観察されました
2017 年 9 月 10 日以降、間欠的に 2~5 回観察されたことですが、~
太平洋夏時間 2017 年 9 月 8 日 15 時 13 分以降ずっと~
太平洋夏時間 2017 年 9 月 8 日 15 時 13 分から同 22 時 22 分まで~
発生時刻と期間を具体的に示せば、クラウド プロバイダーのサポート チームはその期間の時系列モニタリングに注力できます。問題がまだ続いているのか、過去に発生しただけなのかを明確にしましょう。問題が収まっているのなら、それを明確にし、可能なら終期をサポート チームに伝えてください。
また、タイム ゾーンを忘れないようにしましょう。曖昧さがなく、ソートしやすい ISO 8601 形式を使うことをお勧めします。相対的な方式で時刻を記載してしまうと、相手は時系列モニタリング ツールに時刻を入力するために、ローカル タイムを絶対形式に変換する必要が出てきます。この変換作業はミスの元であり、コストもかかります。たとえば、「昨日のもっと早い時間」に何かが起きたというようなメールを送ると、相手はメール ヘッダを探し、頭の中で発生日時を計算しなければなりません。すると、認知的負荷が発生し、技術的な問題の解決に向けられる精神的エネルギーが減ってしまいます。
ある期間に問題が間欠的に起きた場合は、最初に観察されたときか、問題が確実に発生していなかった過去の時点を記載し、観察された頻度を入れ、具体例を 1~2 件示すとよいでしょう。
避けるべきアンチパターンを挙げておきます。
今日早く : 十分に特定できていません。
昨日 : 連絡を受け取った側が暗黙の日付を明らかにしなければなりません。特に日付変更線をまたがる場合は曖昧になります。
9/8 : 曖昧です。米国では 9 月、他の地域では 8 月だと解釈される恐れがあります。明確にするために ISO 8601 形式を使いましょう。
イシュー レポートでは使用している製品をできる限り具体的に示し、必要に応じてバージョン情報も追加してください。たとえば、次のような表現では具体性が足りず、診断に役立つコンポーネントやログを特定できません。
REST API がエラーを返しました。
データ マイニングのクエリ インターフェースがハングアップしています。
理想を言えば、特定の API や URL を指定するか、スクリーンショットを添付したいところです。問題が起きたのが特定のコンポーネントやツールであれば(たとえば CLI や Terraform)、それを明確にしましょう。複数の製品が関与している場合は、一つひとつを明確にします。そして、観察した動作と、こうなるはずだと思っていた動作を記述します。
以下はアンチパターンです。
仮想マシンを作成できません。仮想マシンをどのようにして作ろうとしたのかがはっきりしません。エラー モードがどうなっているのかもわかりません。
CLI コマンドがエラーを返します。
エラーの内容を具体的に書き、コマンドの構文を明示して、他の人も実行できるようにしましょう。
より良い書き方 : “mktool create my-instance --zone us-central1” を実行したところ、次のようなエラー メッセージが返ってきました。
クラウド プロバイダーはリージョンやゾーン全体に変更をロールアウトすることが多いので、リージョンとゾーンを明確にすることは重要です。リージョンやゾーンの情報は、クラウドで稼働するソフトウェアのバージョン番号の代わりになります。
イシュー レポートへの位置情報の記載例を見てみましょう。
us-east1 において~
リージョン eu-west-1 と eu-west-3 で試したところ~
位置情報があれば、クラウド プロバイダーのサポート チームはその場所でロールアウトが行われているかどうかを確かめたり、位置情報から社内リリース ID を割り出して社内用のバグ レポートで報告したりすることができます。
多くのトラブルシューティング ツールにはプロジェクトの識別子が含まれています。エラーが発生したのは複数のプロジェクトなのか、それとも特定のプロジェクトだけなのかをはっきりさせましょう。
具体的な識別子とは、たとえば次のようなものです。
プロジェクト 123412341234 または my-project-id で~
複数のプロジェクト(123412341234 が含まれます)にわたって~
社内のゲートウェイ 56.56.56.56 からクラウドの対外 IP 218.239.8.9 に接続するとき~
IP アドレスは曖昧さのない識別子の 1 つですが、イシュー レポートで使用する場合は追加の詳細情報が必要です。IP アドレスを指定するときは、どのように使われているかも書くようにしましょう。たとえば、その IP が VM インスタンスに接続されているのか、ロード バランサやカスタム ルートに接続されているのか、あるいは API エンドポイントなのかといったことを明確にしてください。IP アドレスがクラウド プラットフォームの一部でなければ(たとえば、ホーム インターネット、VPN エンドポイント、外部モニタリング システムなど)、その情報も追加します。192.168.0.1 は世界中で無数に使われていることを忘れないようにしましょう。
以下はアンチパターンです。
弊社インスタンスの 1 つにつながりません : 曖昧すぎます。
インターネットから接続できません : 曖昧すぎます。
5W1H(ジャーナリズムなどでよく使われています)などのモデルも、イシュー レポートを構造化するうえで役に立ちます。
問題発生の影響と回答に対する要望の明確化
クラウド プロバイダーに対するイシュー レポートには、問題の発生がビジネスに及ぼす影響や、希望する回答期限なども含めるようにします。
クラウド プロバイダーは、イシュー レポートの回覧や緊急度の判定の際に、顧客が指定した優先順位を使います。優先順位は対処のスピードを左右し、緊急だと判断されればオンコール担当者が呼び出されることもあります。
適切な優先順位以外に効果的なのが、どのような影響があるかの説明です。P1 を選んだ理由を明確にして、間違った思い込みをされないようにしてください。
優先順位はビジネスへの影響度を考慮して決めましょう。優先順位の厳密な定義を有しているクラウド プロバイダーもありますが(たとえば P1 は全面的なダウン)、そうした定義のせいでビジネス クリティカルな問題の解決が遅れることは避けなければなりません。問題が解決されない場合に予想される影響や最悪のシナリオをレポートに含めるようにしましょう。たとえば、次の 2 つの例は実質的に P1 に相当します。
バックログが増えてきています。現時点での影響はまだ小さいですが、12 時間以内に解決されなければ、システムは実質的にダウンした状態になります。
重要なモニタリング コンポーネントがエラーを起こしています。現時点では影響はありませんが、監視できない個所が生じており、それによってユーザーにもわかる機能停止が起きる恐れがあります。
回答期限に関して具体的なニーズがある場合は、それを明確に示しましょう。たとえば、「シフトが終了する午後 5 時までに回答をお願いします」とレポートに記します。緊急時の連絡に関する SLO が社内で規定されている場合は、その SLO を満たす形で回答期限を指定します。多くのクラウド プロバイダーは 24 時間 365 日体制のサポートを提供していますが、そうでない場合や担当者のタイム ゾーンがずれている場合は、タイム ゾーン固有のニーズをプロバイダーに伝えましょう。
これらの詳細情報をイシュー レポートに含めれば、あなたの時間を無駄にせず、プロバイダーの修復作業全体をスピードアップさせる効果があるはずです。実際のトラブルシューティング プロセスにおいてクラウド プロバイダーとどのようなコミュニケーションを取るべきかについては、後編をご覧ください。
SRE vs. DevOps
SRE の教訓 : Google におけるインシデント管理とは
エスカレーション ポリシーの適用 : CRE が現場で学んだこと
Special thanks to Ralph Pearson, J.C. van Winkel, John Lowry, Dermot Duffy and Dave Rensin
* この投稿は米国時間 5 月 31 日、Luke Stone と Jian Ma によって投稿されたもの(投稿はこちら)の抄訳です。
- By Luke Stone and Jian Ma
クラウド時代のトラブルシューティング : 解決に役立つプロバイダーとのコミュニケーション(後編)
2018年7月6日金曜日
編集部注 : この記事は、数年前に SRE(サイト信頼性エンジニアリング)の本を出した(本当に!)Google エキスパート チームが執筆してくれました。同書の続編も発売に向けて準備が進んでいるようです。ここでは、多くの IT チームにとって重要な SRE の一分野である、クラウド コンピューティング時代のトラブルシューティングを取り上げます。今回は 2 回連載の後編です。クラウド プロバイダーのサポート部門に送るイシュー レポートの基本的な書き方については前編をご覧ください。
コンピュータ システムのトラブルシューティングは、コンピュータそのものと同じくらい古くから行われており、職人技とまで言われることもあります。ところが、クラウド コンピューティングのパラダイムにより、IT チームによるトラブルシューティングの方法は根本的に変わろうとしています。
IT トラブルシューティングは、運や経験だけで成功させられるようなものではありません。教えることや学ぶことのできる意識的な仕事です。クラウド インフラストラクチャを使用する場合は、クラウド プロバイダーのヘルプ デスクを介してトラブルシューティングを行うことが多く、ユーザー サポートの階層が 1 つ増えます。このように、従来の IT チーム モデルからシフトしなければならないので、プロバイダーとのコミュニケーションがきわめて重要になります(トラブルシューティングを初動から改善する効果的なイシュー レポートの書き方については前編をご覧ください)。
問題があることをプロバイダーに連絡したら、問題解決に向けて、プロバイダーのサポート チームとの共同作業が始まります。
クラウドにおけるトラブルシューティングの要点
クラウド インフラストラクチャの技術的な問題を診断する担当者は、状況の説明(仮説)と説明の根拠となる証拠を探します。短期的には、問題と関係のあるシステム内の変化を探し出し、問題を緩和して直接的な影響を止めるための第一歩としてロールバックを目指します。それに対して長期的な目標とは、問題の根本的な原因を突き止めて解決し、問題が再発しないようにすることです。
SRE の視点から見ると、トラブルシューティングの一般的なアプローチは次のようになります。
トリアージ : 可能な範囲で問題の影響を緩和する。
検証 : 観察されたことを集約、共有する。
診断 : 観察されたことを説明するための仮説を立てる。
仮説を証明、または反証するテスト方法を見つける。
テストを実施し、結果の解釈を統一する。
次の仮説に移り、問題が解決するまでこのプロセスを繰り返す。
クラウド プロバイダーと協力して問題のトラブルシューティングにあたる場合は、自分ではコントロールできない部分がいずれ出てきます。しかし、あなたにはあなたの側で行うべきことがあります。クラウド プロバイダーのサポート チームに報告を送るときに行うべきことは次のとおりです。
1. すでに自分で行ったトラブルシューティングの内容を伝える
イシュー レポートを送るまでに、たとえばプロバイダーのステータス ページをチェックするなど、おそらく何らかのトラブルシューティングをすでに行っているはずです。実施したことと、それによってわかったことをプロバイダーに知らせましょう。実施したことのタイムラインとログ ブックを残しておき、プロバイダーと共有してください。問題が発覚した後は、できる限り早い段階からログ ブックを残すようにしなければならないということです。
インフラストラクチャの状態をリアルタイムで把握できるようにする遠隔測定の手段をクラウド プロバイダーが有している場合もあります。しかし、あなたのシステムの特定の実装に起因する依存関係は自明ではないかもしれません。設計上、クラウド リソースの特定の利用方法は非公開かつプロプライエタリであるため、見晴らしのきくあなたの視点はきわめて重要です。
問題を診断できていると判断したときは、その結論に至った経緯を説明しましょう。ほかの人間でも問題を再現できるようであれば、そのための手順も説明に含めます。再現可能なテストがイシュー レポートに含まれていると、通常は最速での解決につながります。
ただし、推理の根拠となるような証拠を探すあまり、反対証拠を無視して確証バイアスに陥らないように注意してください。
2. 問題を明確かつ具体的に示す
1 列に並んだ人々が順に次の人にメッセージをささやく伝言ゲームをしたことがあれば、人の解釈や言い換えによってコミュニケーション ギャップが生じることをよくご存じでしょう。プロバイダーとのやり取りでは、情報を一方的に説明するのではなく、シェアするようにしてください。そうすれば、あなたが言っていることを相手が誤解する可能性が低くなり、トラブルシューティングのスピードアップにつながります。プロバイダーならすべての情報を知っているはずだと思い込んではなりません。設計上、顧客のプライバシーに関わる事項については、プロバイダーが知っていることは限られます。
情報のシェアは、たとえば次のようにします。
見たとおりのものを示すため、スクリーンショットを添付する。
ウェブ ベースのインターフェースとして HAR(Http Archive)ファイルを提供する。
tcpdump 出力、ログの一部、サンプル スタック トレースなどの情報を添付する。
3. 本番アウテージは早い段階で報告する
アプリケーションがユーザーにトラフィックを送信しなくなったり、同等の重大な影響をビジネスに及ぼすようになったりしたら、それは本番アウテージと見なされます。本番アウテージが発生したら、クラウド プロバイダーのサポート部門にできる限り早く知らせましょう。なお、開発者用のテスト環境で少数の開発者がアクセスできなくなるような問題が起きても、それは本番アウテージとは見なしません。報告の優先順位も低くなります。
通常、クラウド プロバイダーのサポート チームに本番アウテージを知らせると、彼らは次の手順ですぐにトリアージに着手します。
インフラストラクチャに影響を及ぼす既知の問題を直ちにチェックする。
問題の性質を確認する。
通信チャネルを開設する。
一般に、次の内容を含む簡潔なメッセージをプロバイダーに送ると、すばやい対応が期待できます。
複数の顧客に影響を及ぼす既知の問題の有無
報告した問題をプロバイダー側で観察することの承認や、詳細情報のリクエスト
希望する通信手段(たとえば、電話、Skype、イシュー レポート)
大切なのは、4 つの必須情報(前編で説明)を含むイシュー レポートをすぐに作成し、そのあとで自分の側のトラブルシューティングを深めていくことです。あなたが所属する組織がインシデント管理プロセス(SRE 本のインシデント管理の章を参照)を定義している場合は、クラウド プロバイダーへのエスカレーションを早い段階で行う必要があります。
4. ネットワーク関係の問題はとりわけ具体的に報告する
多くの場合、クラウド プロバイダーのネットワークは膨大かつ複雑であり、さまざまなテクノロジーやチームが関与しています。そうした中で重要なのは、ネットワーク固有の問題をすばやく特定し修復できるチームと協力して作業を行うことです。
ネットワークに関連する問題の多くは、「サーバーに接続不能」というように、類似した症状を示します。このレベルの報告は漠然としており、根本的な原因を突き止めるうえで役には立ちません。もっと多くの診断情報を提供する必要があるのです。接続関連のネットワーク障害には少なくとも 2 つの地点(送信側と受信側)が関わっています。ネットワーク関連の問題を報告するときは、これらの地点に関する情報を必ず含めるようにしてください。
イシュー レポートを作成する際はパケット フロー図の概念ツールを使用しましょう。
パケットの送信側から受信側までの経路における重要なホップと、経路に沿って行われる重要な変換(たとえば NAT)を書き出す。
最初に、インターネット IP アドレスまたは RFC 1918 プライベート アドレスと、ネットワークの AS 番号を用いて、影響を受けたネットワーク エンドポイントを識別する。
エンドポイントの管理者、DNS ホスト名との関連の有無など、エンドポイントに関して意味がある情報を書き込む。
VPN トンネル、プロキシ、NAT ゲートウェイなど、間に入るカプセル化や間接参照の情報を書き込む。
ファイアウォール、CDN、WAF など、途中のフィルタリングの情報を書き込む。
レイテンシの増加やパケットの消失といった形で現れる問題を診断するには、パス分析やパケット キャプチャが必要です。パス分析とは、パケットが通過するホップのリストです(たとえば MTR や tcptraceroute で取得)。パケット キャプチャ(pcap。名前はライブラリ名の libpcap に由来)は、実際のネットワーク トラフィックを観察することです。難しい場合もありますが、両方のエンドポイントで同時にパケットをキャプチャすることが重要です。必要なツール(たとえば tcpdump や Wireshark)の使い方に慣れ、必要になる前にインストールしておくようにしてください。
5. 必要に応じてエスカレーションする
状況の変化次第では、問題の緊急度を引き上げて、プロバイダーにすぐに対処してもらわなければならないこともあります。ビジネスへの影響が大きくなったり、サポート部門といくらやり取りしても状況の進展が見られなかったり、その他の要因で早期解決が必要になったりした場合はエスカレーションを要求します。
最も明確なエスカレーションの方法は、イシュー レポートの優先度の変更です(たとえば P3 から P2)。エスカレーションが必要な理由をコメントの形で提供し、サポート部門が適切に対応できるようにしましょう。
6. 長く続く問題や困難な問題についてはサマリー ドキュメントを作成する
時間の経過とともに、新しい事実に光が当てられたり、仮説が除外されたりして、問題の状態や関連情報は変化していきます。その間に新しい担当者が調査に参加することもあるでしょう。そのような場合に備えて、サマリー ドキュメントに情報を集約し、最新の情報が伝達されるようにしておいてください。
優れたサマリー ドキュメントには次のような特徴があります。
最新の状況が冒頭にまとめられている。
すべての関連イシュー レポートや社内バグ管理情報へのリンクがまとめられている。
正しいかもしれない仮説と、すでに除外された仮説のリストがまとめられている。特定の仮説について検証を開始するときはそのように書き、使用する予定のテストやツールを明らかにする。そうすることで、適切なアドバイスをもらえたり、作業の重複を避けたりすることができる。
以下はサマリー ドキュメントの書式例です。
顧客への影響は緩和され、解決された。先月の使用料の支払いを忘れたため、ネットワーク プロバイダーが当社のトラフィックを制限している。今後は財務部門との連絡を強化したい。
当社のサービスに接続できないとの苦情が 100 人以上の顧客から寄せられている。ネットワーク プロバイダーは、顧客トラフィックの処理を 1 個のロード バランサだけに絞っている。対策チームは、ネットワーク プロバイダーのティア 1 サポートと協力して、この問題が発生した理由と経緯を調査している。
api.acme.com の API に継続的に接続できないという苦情が、4 つの異なる地域の 50 人の顧客から 100 件届いている。当社のエンジニアは上流のネットワークに問題があると考えている。次のステップは、ネットワーク プロバイダーに連絡を取り、上流に問題があるかどうかを確かめることである。
api.acme.com に接続できないという苦情が 5 人の顧客から届いている。当社のエンジニアが問題を調査している。
個々のイシュー レポートでは 1 つの問題だけを扱うようにしてください。新しい問題が以前の問題に関連しているからといって、以前の問題のイシュー レポートを再度使用してはなりません。新しいレポートにおいて類似の問題の参照情報を提供すると、根本原因によって引き起こされるパターンをプロバイダー側が認識しやすくなります。
コミュニケーション スキルを磨く
細かい技術情報を明確にアクショナブルな形で伝えることは容易ではありません。そのためには集中と特別なスキルが必要です。ストレスが溜まる場面では、これが特に難しくなります。ストレスに対する生物学的反応が、明快で状況を見据えた推論の足を引っ張るのです。全員に対してわかりやすいコミュニケーションを取るには次のテクニックが役に立ちます。
詳細なイシュー レポートを書いて認知的負荷を下げる
イシュー レポートを読み進めるにあたって、推論や計算が必要になることがあります。これが認知的負荷を生み出し、技術的な問題の解決に使える精神的エネルギーを減退させます。
イシュー レポートは、できる限り具体的かつ詳細に記述するようにしてください。細部に注意を払うと、そのぶん作成にかかる時間は増えます。とはいえ、作成されたイシュー レポートは多くの人に何度でも参照されることになるため、全員が包括的な情報を得ていれば問題を早く解決できます。
また、イシュー レポートには略語や社内のコード名などを使わないようにしてください。第三者に情報を開示するときも、顧客のプライバシー保護に十分配慮しましょう。
ナラティブ(ストーリー テリング)のテクニックを使う
“昔々あるところに…”
人間は、ストーリーの形になっている情報の吸収に特に長けています。そこで、この能力を活用すれば、効果的に論点を理解してもらえます。状況説明から始めてください。初めて問題を観察したときに何が起きたか、どのような解決方法を試みたか、誰が関与していたか、彼らにとってその事象はなぜ問題だったのか。テキストの書式やグラフ、スクリーンショットなどのイメージを活用して、イシュー レポートにビジュアルな要素を組み込みましょう。
ログ データ、コードの一部、MySQL の結果といった書式のあるテキストをプレーンテキスト メールの一部として送信すると、見分けがつきにくくなります。そこで、マーカーを意識的に追加すれば(たとえば引用の最終行に <<<<<< を入れる)、重要な部分に注意を向けやすくなります。また、長い URL については脚注を活用するか、URL 自体を短くするようにしてください。
項目を列挙する場合は、箇条書きリストを使用し、インスタンス名などの重要な細部については目立つようにします。手順の箇条書きには番号を付加してください。
時系列データをわかりやすくするうえで、グラフはとても効果があります。イシュー レポートにグラフを添付するときは、以下のベスト プラクティスを常に心がけましょう。
タイトルや軸ラベルを付けた状態でスクリーンショットを取得する。絶対数には単位(分あたりのリクエスト数、秒あたりのエラー数など)を付加する。
スクリーンショットに矢印や丸でコメントを付け、重要なポイントを目立たせる。
何を測定しているグラフなのかを簡潔に説明する。
正常な場合のグラフがどのような形になるかを簡潔に説明する。
グラフに対する自分なりの解釈、問題との関連を簡潔に説明する。
次のアンチパターンに注意してください。
Y 軸が個別的なエラー(たとえば自分のハンドラ内の例外数)を示しており、調査中の問題(たとえば永続化レイヤのレイテンシ)との関係がはっきりしない。このような場合は、問題にとってこのグラフがなぜ重要なのかを説明する必要がある。
Y 軸が絶対数(たとえば 1 分あたりの数)になっていて、相対的な影響についての手がかりが得られない。
X 軸にタイム ゾーンの指定がない。
Y 軸が 0 から始まっていない。これでは Y 軸の値のわずかな差が非常に大きく見えてしまう。
軸ラベルがなかったり、消されたりしている。
きちんとしたイシュー レポートを作成し、クラウド プロバイダーと緊密にコミュニケーションを図ることができれば、問題解決のペースが上がり、解決に要する時間が短縮されます。
コンピュータ システムのトラブルシューティングは、クラウド コンピューティング モデルの登場によって大きく変わりました。もはや、技術的知識が豊富であれば効果的なトラブルシューティングが可能だという時代ではありません。クラウド プロバイダーとの間で明快かつ効率的にコミュニケーションを図る必要があるのです。
デプロイされた実際の環境が特異で複雑、しかも微妙な部分を含んでいるとしても、この連載の内容が効果的なトラブルシューティングを手助けしてくれるでしょう。
SLO、SLI、SLA について考える : CRE が現場で学んだこと
SRE vs. DevOps: competing standards or close friends?
Google の新しい専門職 : CRE が必要な理由
Special thanks to Ralph Pearson, J.C. van Winkel, John Lowry, Dermot Duffy and Dave Rensin
* この投稿は米国時間 5 月 31 日、Luke Stone と Jian Ma によって投稿されたもの(投稿はこちら)の抄訳です。
- By Luke Stone and Jian Ma
株式会社バンダイナムコスタジオ様の導入事例動画: Google App Engine の活用で、ゲームリリース後のトラブルとは無縁の「平和な日々」という驚きを体験
2018年7月4日水曜日
ゲームアプリ「アイドルマスター ミリオンライブ! シアターデイズ」(配信元:株式会社バンダイナムコエンターテインメント)の開発にあたり、株式会社バンダイナムコスタジオは Google Cloud Platform(GCP)の導入を決断します。
Google App Engine(GAE) は、スケーリングが極めて高速であり、突発的なアクセス数増加にも柔軟に対応することが可能です。この GAE を活用し、大きなメリットを生み出した同社の事例をご紹介します。
■ 利用している Google Cloud Platform サービス
Google App Engine、Google Kubernetes Engine、Cloud Datastore、BigQuery、Google Stackdriver など
■ 株式会社バンダイナムコスタジオ
アーケードや家庭用ゲームの他、モバイル向 けのソーシャルゲームにも積極的に取り組み 多くのヒットを生み出しています。「Innovation through Creativity」を スローガンに時代の先頭に立ち、新たな広がりと深み をもった数々の人気ゲームタイトルを世に送り出すことで、社会に「夢・遊び・感動」を 提供することをモットーにしています。
IaaS ベースのインフラの課題とソーシャルゲーム運用の難しさ
数多くの人気コンテンツを提供する株式会社バンダイナムコスタジオ。同社のモバイル用ゲームコンテンツの提供は i モード時代の 1999 年からで、当初システムはオンプレミスでしたが、2012 年頃から、あるクラウドサービス(IaaS)への移行を始めました。
ただ、この IaaS サービスにはいくつか課題があったと保科さんは言います。「大量のアクセスのため、コンテンツによっては十数台のデータベースサーバーを並列化して運用するのですが、サーバーが増えれば増えるだけ障害発生率も増加していたのです。また IaaS では 1 度データベースの構成を決めると、サーバーの増減は簡単ではありません。さらにフロント側の Web サーバーのスケーリングでは、台数の変更に時間がかかり、実際のアクセス増減にうまく追従できない問題がありました。」(保科さん)
ソーシャルゲームでは、リリース直後、テレビ CM 放映時、ゲーム紹介の動画配信などをきっかけに「スパイク」と呼ばれる急激なアクセス数の増加が発生します。「スパイクの発生を予測することは極めて困難です。SNS など我々の知らないところで注目が集まり、それをきっかけに爆発的なアクセスが殺到しスパイクが発生することもあります。」(八重樫さん)
スパイクが発生した際、Web サーバーを迅速にスケールアウトして台数を増やせば、レスポンス低下などの問題を避けられますが、スパイクが去ってアクセスが落ち着いた後に、増やした台数を元に戻さなければ、無用なコストが発生し続けます。従来の IaaS では、このようなアクセス数の増減に完全に自動的には追従できず、人手による監視や運用の手間が随時発生する課題がありました。
またデータベースについても、実際のアクセスにより必要となった規模・処理能力が、最初の見積もりを外した場合は、適正な構成に変更するまで、辛いメンテナンスの時間を過ごすことになります。
こうした背景から今回のゲームアプリ「アイドルマスター ミリオンライブ! シアターデイズ」(配信元:株式会社バンダイナムコエンターテインメント)の開発にあたって、同社は Google Cloud Platform(GCP)の導入を決断します。
「アイドルマスター ミリオンライブ! シアターデイズ」
(配信元:株式会社バンダイナムコエンターテインメント)
©窪岡俊之 ©BANDAI NAMCO Entertainment Inc.
「今回のゲームでは、サービス開始後にどの程度のアクセス数が集まるか予測できず、適切なデータベースや Web サーバーの規模を事前に決めることは困難でしたが、その頃 Google App Engine(GAE)について知り、データベースの Cloud Datastore がほぼ無制限の自動スケール性能を持つこと、Web サーバーのプログラミング言語に Go を使えば起動がすごく速く、スパイクを含むアクセス数の極端な増減にも自動で対応できることを知りました。実際にテストでも、よい手応えを感じられ、よし GCP を使ってみよう!と考えました。」(保科さん)
GCP の採用においては、エンジニア側の熱意も大きかったようです。「GAE と Datastore、Go 言語でやりたいという思いがエンジニアにすごくあったんです。社内からは、本当に GAE で大丈夫かという声もありました。そこで事前に負荷試験を実施したり、GCP パートナーの協力のもと開発体制を整えたりと取り組みを進めました。そういった社内での努力、エンジニア以外のステークホルダーに向けたアピールの甲斐もあり、最終的に GCP の採用に至りました。」(保科さん)
Google App Engine の活用でエンジニアが開発に集中できる環境を構築
本ゲームの開発は、GAE で行われました。大量アクセスへの対処は、検証時の負荷テスト時に想定される 2 倍以上の負荷をかけ問題がないことを確かめました。サービスインした 2017 年 6 月 29 日正午、当時を宮野さんは次のように振り返ります。
「サービスイン後、サーバーエンジニア全員で、Stackdriver Logging や Stackdriver Monitoring を使ってモニタリングし、さらにお客さまが SNS で発信する生の反応をチェックしながらサーバーの状況を見守りました。予想以上のお客さまに遊んでいただき、リセマラ(リセットマラソン)もありましたが、アクセス数の増加、スパイクによるトラブルは発生せず、期待以上の安定動作で大量のアクセスを耐えきってくれました。ゲーム操作を自動化するプログラムボットのアクセスも多数確認されましたが、GAE の自動スケール性能を上回ることはなく、お客さまのアクセスには影響しませんでした。」
公開から半年以上が経過した今も、Cloud Datastore を含むサーバーインフラの構成変更は 1 度もなく、すべては GAE の自動スケールで運用されており、サーバーアプリケーションの更新もサービスを停止せずに行われています。運営中も絶えず開発が必要なソーシャルゲームにおいて、完全無停止の自動化インフラ運用がもたらすメリットは極めて大きいといえます。この安定稼働について、1 つの大きな利点は GAE のバージョン機能です。本機能は、バージョンアップの際、従来の環境に手を加えず、別系統として新バージョンを用意しておき旧バージョンから瞬間的に切り替えられます。
「デプロイが本当にしやすいんですよね。秒間数千リクエストがあり、かつ数百のインスタンスが稼働している状況でも、バージョン機能なら普通に新しいバージョンに切り替えられます。」(保科さん)
「従来は、デプロイのためのインフラ安定のために、大変な時間と労力を要していました。また運用中のデプロイは完了までに数 10 分かかったり、サービスが不安定になったりするリスクが伴うのですが、GAE なら、バージョン機能で瞬間的かつ安全に切り替えられるし、問題があったら即座に元のバージョンに戻せる。これは感動しましたね。」(八重樫さん)
さらに八重樫さんは、GCP は運用でよく使われるユースケースがしっかり考えられていると話します。「GAE のバージョン機能のように、『普通、こう作るよね』という仕組みが、はじめからわかりやすい形でドキュメントと共に用意されていて、期待通りに動いてくれる。これはすごく重要なことです。不要な試行錯誤をせずとも GCP の機能をフル活用できたのは本当にありがたかった。」
今回は、ログ解析基盤として BigQuery が使われています。ゲームシステムからのログは膨大で、社内のログ解析基盤では処理しきれないほどでしたが、BigQuery は、タイミングやクエリの性質を気にせず、任意のログを探し出すことがスムーズに行えたと評価します。
「今回のプロジェクトで、BigQuery はあらゆるところで活用されています。特に Stackdriver Logging との連携により、アクセスログが 1 日や 1 時間などではなく 1 分未満のディレイで BigQuery のテーブルにストリーミング挿入され、それに対して様々なクエリを発行できる機能があり、これにより直近 1 分から数ヶ月といったスパンのアクセス分析をリアルタイムに実施できます。様々な不具合や障害に対する早期対応には BigQuery は欠かせません。」(八重樫さん)
今回の GCP の導入効果を振り返ると、インフラ運用負荷の大幅な低減があったと言います。「IaaS ベースですと、仮想マシンに必要なソフトウェアのインストール・設定、独自開発など、ある程度はエンジニアをインフラ運用や開発に割かざるを得ないんです。でも GAE なら、そのような時間は全体からみたらごくわずか。エンジニア全員がゲーム開発に注力できました。」(宮野さん)
他の Google サービスとの統合による利便性の高さも大きかったと語るのは八重樫さんです。「クラウドのコンソールへのアクセスや、ゲーム管理画面へのログインなどでも Google アカウントが使えるので、新たに認証・認可の仕組みがいらないことは楽でした。Google アカウントはほぼ皆使っているので、新規メンバーでも即座にプロジェクトに入れますし、シームレスに使える Google スプレッドシートも、自動化のスクリプティング環境や API が整備されており、よいところを挙げるときりがありません。Excel ファイルの添付メールが飛び交っていた頃とは一線を画していると思います。」
「GAE や Google サービスを活用できるまでには相応のコストが必要でしたが、トータルではそれを上回るメリットが得られました。GAE と Go 言語による開発で最大のパフォーマンスを引き出すには、設計思想やベストプラクティスの理解が必要です。今回短期間での開発の達成には、我々の努力や覚悟以外にも、有償トレーニングや高度なサポートプランといったプロフェッショナルの力を借用するコストが必要でした。しかしその苦労やコストと引き換えに、ゲームリリース後の我々の労力は大幅に軽減され、今は平和な日々を送れていることは、大いに強調したいですね。」(八重樫さん)
株式会社バンダイナムコスタジオの導入事例 PDF はこちらをご覧ください。
GCP のその他の導入事例はこちらをご覧ください。
ラベル: App Engine , GCP導入事例
Cloud OnAir 番組レポート :ビッグデータ事例紹介 - e-Learning 編
2018年7月3日火曜日
Cloud OnAir は、Google Cloud の製品をわかりやすく解説し、最新の情報などをいち早く皆様にお伝えする Online LIVE 番組です。
6 月 28 日の内容は、前回(6 月 21 日)に放送した「Cloud OnAir 番組レポート :ビッグデータ事例紹介」の e-Learning 編です。今回は、マーケティングデータを例にビッグデータを分析する過程を学びます。広告配信データ、ソーシャルメディア、企業内データといった複数のデータソースを統合した高度なデータ分析を実践する際の基本的な知識を身につける内容となっています。
Google アナリティクス 360 Suite に蓄積された Google Merchandise Store のログデータ(デモ用)を利用して、BigQuery で分析
Google Colaboratory を利用した分析例
6 月 28 日放送: ビッグデータ事例紹介 - eLearning 編
番組で説明した資料はこちらで公開しています。
[Cloud OnAir] ビッグデータ事例紹介 データ分析と実践編 (e-Learning) 2018年6月28日 放送 from Google Cloud Platform - Japan
Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
ラベル: Cloud OnAir , Google Cloud
進化する Google Cloud マネージド データベース
2018年7月3日火曜日
1」と指摘しており、Google Cloud のお客様の場合もこの流れの例外ではありません。
マネージド データベース サービスは、ベースにあるインフラストラクチャを抽象化します。したがって、お客様はサーバーやラック、レプリケーションのことを気にせずにデータベースや API を扱えます。Google Cloud は、お客様の間で人気の高いオープンソースのデータストアや、Google が長年培ってきた独自技術のマネージド データベース サービスを提供する戦略を取っています。
Google は先ごろクラウド データベースのアップデートを発表しました。それは以下のとおりです。
Cloud Spanner の commit タイムスタンプ機能を提供
Cloud Bigtable のレプリケーション機能をベータ リリース
Cloud Memorystore for Redis をベータ リリース
Cloud SQL for PostgreSQL を正式リリース
Cloud Spanner の commit タイムスタンプ機能
Cloud Spanner は、リージョンや大陸をまたいだ形で外部(強)整合性をサポートする唯一の分散リレーショナル データベースです。この機能は企業に新たな機会をもたらします。昨年 5 月に正式提供が開始されて以来、Optiva や Bandai Namco のような多くのお客様が、Cloud Spanner 上にミッションクリティカルなシステムを構築しています。
私たちはこれからもお客様本位を貫き、お客様の要望に基づいて機能を拡充していきます。最近では、ミューテーションの正確な順序の判断や、変更履歴の作成に役立つ commit タイムスタンプ機能を Cloud Spanner に追加しました。
Cloud Bigtable のレプリケーション機能
私たちは最近、Cloud Bigtable のリージョナル レプリケーション機能をベータ リリースしました。この機能は、可用性や読み取りスループット、耐久性を向上させ、ゾーンで障害が発生した場合に復元できるようにします。ボタンをクリックするだけで、1 つの GCP リージョン内のゾーン間で Cloud Bigtable データセットが非同期にレプリケートされ、スケーラブルでフルマネージドのレプリケートされたワイドカラム データベース サービスが提供されます。低レイテンシ、ランダム データ アクセス、スケーラビリティが重要な場合に効果的です。
Cloud Memorystore for Redis ベータ版
これまで多くのお客様からマネージド Redis のサポートを求める声が寄せられてきました。そこで、私たちは今年 5 月から Cloud Memorystore for Redis のベータ版を提供しています。Redis に対応したこのフルマネージド インメモリ データストア サービスは、スケーラブルで、十分なセキュリティを確保し、高い可用性を備えています。Redis プロトコルと互換性があり、コードを変更することなくアプリケーションを移行できます。
Redis は、アプリケーション キャッシュ、ゲームのリーダーボード、増分カウンタといったソリューションの開発に広く使われています。高速なインメモリ キャッシング、強力なデータ構造、レプリケーションやパブリッシュ / サブスクライブのような機能のおかげで、Redis は低レイテンシが求められるユース ケースにうってつけです。
Redis はスタンドアロン インスタンスとしてデプロイできるほか、高可用性を確保するためにレプリケートすることも可能です。Cloud Memorystore ではインスタンスのセットアップと管理に関わる運用上のオーバーヘッドが解消されており、アプリケーションに必要な機能を簡単にデプロイできます。
Cloud SQL for PostgreSQL の正式リリース
Cloud SQL での PostgreSQL のサポートは、データベース分野においてお客様から最も要望が多かった事項です。Cloud SQL for PostgreSQL は先ごろ正式提供が開始されました。ベータ期間中は、高可用性、レプリケーション、高パフォーマンス インスタンス(最大 416 GB の RAM を搭載)、19 の拡張機能のサポートといった強化が施されました。また、HIPAA の適用を受けるお客様のために、このデータベース サービスは Google Cloud Business Associates Agreement(BAA)の対象に加わっています。
高可用性機能を備える Cloud SQL for PostgreSQL は、Google Cloud のサポート対象であるとともに、SLA によって全世界で 99.95 % の可用性が保証されています。データベース技術の格付けを行っている独立系サービスの DB-Engines は、“DBMS of the Year 2017” に PostgreSQL を選定し、その理由として爆発的な普及拡大を挙げています。
マネージド データベース サービスへの移行を容易にするため、Cloud SQL for PostgreSQL では標準のオープンソース PostgreSQL が実行されます。また、Google が PostgreSQL に対して行った改良はすべてコミュニティに還元される予定です。
私たちはこれからもマネージド データベース ポートフォリオに新しいサービスや機能を取り入れていきます。さらなる展開にご期待ください。お客様のデータが増大し、変化するのに合わせて、データベースも進化しなければなりません。エンジンの選択、スコープ、機能、信頼性、使いやすさのいずれにおいてもです。
私たちの目標は、お客様のデータにおいて高いアクセス性、セキュリティ、可用性を確保し、お客様にビジネスに集中していただける最も完全なマネージド データベース サービスのスイートを提供することです。お使いになりたいマネージド データベース サービスがありましたら、ぜひ、どのようなものかお知らせください。
1 資料 : Gartner IT Market Clock for Database Management Systems 2018(著者 : Donald Feinberg、Adam M. Ronthal、Ankush Jain、2018 年 1 月 18 日発表)
* この投稿は米国時間 4 月 25 日、Director of Product Management の Dominic Preuss によって投稿されたもの(投稿はこちら)の抄訳です。
- By Dominic Preuss, Director of Product Management
ラベル: Cloud Bigtable , Cloud Memorystore , Cloud Spanner , Cloud SQL , Postgre , Redis
Cloud SQL for PostgreSQL を正式リリース
2018年7月2日月曜日
Google Cloud Platform(GCP)のお客様からも要望が多いサービスの 1 つです。このほど、フルマネージド データベースの Cloud SQL で PostgreSQL サービスが正式リリース(GA)され、Cloud SQL のすべてのお客様が利用できるようになりました。
SRE チームによる 24 時間 365 日のサポート、高可用性と自動フェイルオーバー、Google SLA を特徴とする Cloud SQL for PostgreSQL は、本番ワークロードに求められる要件を十分にクリアしています。Google Cloud の強力で信頼できるインフラストラクチャの上に構築され、基幹ワークロードをサポートできるスケーラビリティを有し、世界中のあらゆる場所で 99.95 % 以上の可用性を確保しつつ、バックアップやレプリケーション、パッチ、アップデートをすべて自動化します。Cloud SQL を採用すれば、IT 運用ではなくアプリケーションに全力を注ぐことができます。
Cloud SQL for PostgreSQL はベータ リリースの時点で、高可用性とレプリケーション、最大 416 GB の RAM を搭載したハイパフォーマンス インスタンス、19 種の追加エクステンションのサポートを実現していました。HIPAA コンプライアンスが必要なお客様のために、Google Cloud Business Associates Agreement(BAA)の対象にもなっています。
Cloud SQL for PostgreSQL は、互換性維持のために標準の PostgreSQL を実行します。また、Google が PostgreSQL に改良を加えるときは、オープンソース コミュニティにコントリビュートして、誰もが使えるようにします。
ベータ期間中は、不動産取引、衛星画像サービス、オンライン リテールなどさまざまな業種の数千社を超えるお客様が、Cloud SQL for PostgreSQL にワークロードをデプロイしました。次節では、データ管理の分散化と事業拡大を目的に Cloud SQL for PostgreSQL を利用しているお客様の事例を紹介します。
Cloud SQL でデータ管理を分散化した OneMarket
OneMarket は世界中でショッピングの形を変えようとしています。データ、テクノロジー、業種間のコラボレーションを通じて、エンドツーエンドのより良いショッピング体験を作り出すことを目指しています。
Westfield Labs と Westfield Retail Solutions で構築された OneMarket は、小売業者、ブランド、ショッピング スポット、パートナーを 1 つにまとめ、データから知見を得るためのコラボレーションを促進し、自然言語処理、人工知能、拡張現実(AR)などの新技術を大規模に実装しています。
OneMarket は、小売業者、ショッピング スポット、技術パートナーを結ぶネットワークのプラットフォームを構築するため、グローバルなロケーションと、Kubernetes Engine や Cloud SQL などのマネージド サービスを提供している GCP を選びました。
「私はビジネス問題に全力を注ぎたいと思っています。私のチームが Cloud SQL for PostgreSQL などのマネージド サービスを使っているのは、品質の高いコードを送り出し、市場投入の時期を早めることに集中するためです。サーバーやシステムの心配をしなければならないとしたら、重要とはいえ直接的には意味のない管理作業に多くの時間を割くことになるでしょう。当社の CTO が言うように、私たちは配管ではなく家を建てたいのです。」
— Peter McInerney 氏、OneMarket の 技術運用担当 VP
OneMarket のプラットフォームは 15 個のマイクロサービスで構成され、それぞれが 1 つ以上のストレージ サービスに支えられています。Cloud SQL for PostgreSQL は、リレーショナル データが必要な部分のマイクロサービスを支えています。
OneMarket チームは、プラットフォームの部品を安全かつスピーディに開発、デプロイ、更新するためにマイクロサービス アーキテクチャを採用しました。それぞれのマイクロサービスは、独立したストレージ サービスによって支えられています。Cloud SQL for PostgreSQL インスタンスは、プラットフォームを構成する 15 個のマイクロサービスの多くを支え、データ管理の分散化と各サービスの独立したスケーリングを実現しています。
「私は時々、2008~2009 年ごろの Westfield Digital のことを考えます。当時のチームは、データセンターに常駐して、サーバーをメンテナンスしたり壊れたディスクを修復したりしていました。今は簡単にスケーリングできます。」
— Peter McInerney 氏
チームがデータベース管理ではなくデータ モデルに注力できるようになったおかげで、OneMarket プラットフォームの開発はスムーズに進みました。現在は本番環境で稼働しており、世界中の顧客のトランザクションをしっかりと処理しています。OneMarket は、BigQuery と Cloud SQL for PostgreSQL を使ってデータを分析し、一般消費者の行動と嗜好に関する知見を世界中の小売業者に提供しています。
Cloud SQL for PostgreSQL のようなクラウド ソリューションを検討している企業への McInerney 氏のアドバイスを紹介しましょう。「とにかく始めることです。まずは非基幹系のサービスを選び、クラウドで動かして自信をつけましょう。」
Cloud SQL for PostgreSQL の使用にあたって
Cloud SQL データベースへの接続は、PostgreSQL データベースへの接続と同じです。標準コネクタや、pg_dump などの標準ツールを使ってデータを移行します。
支援が必要な場合は、Cloud SQL for PostgreSQL に精通している Google Cloud のパートナー エコシステムをお役立てください。データ転送関連では Alooma、Informatica、Segment、Stitch、Talend、Xplenty に、分析データの視覚化関連では ChartIO、iCharts、Looker、Metabase、Zoomdata にご相談ください。
また、こちらのページでサインアップして 300 ドル分のクレジットを入手し、Cloud SQL や GCP のその他のサービスをお試しください。安価なマイクロインスタンスでテストや開発をスタートさせ、準備が整い次第スケールアップすれば、高パフォーマンスのアプリケーションに対応できます。
Cloud SQL for PostgreSQL の正式リリースは大きなマイルストーンではありますが、進歩はまだまだ続きます。公開バグ トラッカーを使ったり、Cloud SQL ディスカッション グループに参加したりして、必要な機能や能力をリクエストしてください。コミュニティへの参加を歓迎します。ご意見やご感想をぜひお寄せください。
* この投稿は米国時間 4 月 18 日、Product Manager の Brett Hesterberg によって投稿されたもの(投稿はこちら)の抄訳です。


document_lang: ja

langs: ja en ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh

text: 東日本大震災後よりボランティア活動を積極的に行い、被災地にも頻繁に足を運び、被災の実際を多くの人に伝えている。 2015年末に体調を崩し、自宅でブロの活動を主にしていたが、現在は徐々に活動の場を広げ始めている。 このブログは彼女のボランティア活動の全てがわかりやすく詰まっている。私の自慢の親友である。


langs: ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja

text:
② ひとりになるとき、どんなとき
③ ひとりだと気づいたら、自分を守る力を発揮する(あんぜんスイッチ)
⑤ 人との距離感を保つ
⑥ 誘いやお願い事は、きっぱり断る
⑦ 危険を感じたら逃げる
⑧ 「助けて」を伝える
⑨ 防犯ブザーの効果 など
プログラム実施上、調整することもありますが、上記のような順番で伝えることがほとんどです。自分だけにならない環境づくり、予防力、距離感、対処力、そして、対処力を補ってくれる防犯ブザーの効果について。一番大切なことは、「①ひとりにならない」をなるべく実践できるよう習慣化することです。
児童・生徒への防犯指導のコツ
日本の場合、小学校低学年でも「子どもだけ」で行動することが多く、地域や大人たちの取り組みととともに、子ども自身も防犯力を身につけておかなければいけない状況にあります。ほとんどの小学校では、全校や各学年を対象に「防犯セミナー」「セーフティ教室」と呼ばれるような防犯指導の機会を設けていますが、年1回程度実施される指導では、とても足りません。
重要なのは、防犯セミナーを「きっかけ」として、授業をはじめ、朝の会・帰りの会などで「ふりかえる」機会や「ふかめる」機会を定期的に設けていただくことです。防犯のコツや安全の大切さは、普段の生活の中で忘れてしまうことも多いからです。シンプルでわかりやすい言葉を使い、くり返し伝えることで、子どもたちの記憶にも残りやすくなります。
また、クイズや参加体験型のプログラムを活用することで、子どもたちが主体的に参加しやすくなります。参加体験的に学ぶ際にはいくつかコツがありますが、「解説」をどこに入れるのか...がポイントになります。ちなみに、私は、子どもたちの様子をみながら、プログラムの順序を下記のように調整しています。
生きる力としての防犯力は、知識や情報として得るだけでなく、実際に声や体を使って確認することで高まるものです。個人的には、まずは声や体を使うゲームなどを行い、「自分を守る力」の視点から防犯に役立つ動きやコツを子どもたち自身に考えてもらう方法が一番良いと感じています。とはいえ、実施時間、会場の広さ、参加人数によっては厳しいことも多いのですが...。
さて、教職員研修でも好評をいただいているのが、ベネッセこども基金とともに制作した、子どもの安全・安心ハンドブック、そして『子どもの安全教室』実施プログラムです。どちらも市民防犯の視点から、子どもたちの防犯対策について具体的にまとめています。実施プログラムは、イラストのデータや、実施のコツについてまとめた資料がセットになっており、座学形式でも参加体験型プログラムでも対応可能です。ハンドブックは、ふりかえり用の教材として、また、保護者のみなさまへのヒントもまとめられています。ぜひ、ご活用ください!
なお、中学生以上への防犯指導については、著書活かそうコミュ力!中高生からの防犯(ぺりかん社)を参照ください。
うさぎママのパトロール教室
うさぎママのパトロール教室主宰
犯罪防止NPOでの活動を経て、2006年より安全インストラクターとして活動を開始。「市民防犯」のパイオニアとして全国で講演やセミナーなど多数実施中。子どもたちを対象とした「安全ワークショップ」も好評を得ている。
著書には「SELF DEFENSE 「逃げるが勝ち」が身を守る」(講談社)ほかがある。
SNSでこの記事をシェアする
よりよい社会をつくる子どもたちを育むために
経済的困難を抱える子どもたちのために
重い病気や障がいを抱える子どもたちのために
子どもの安心・安全を守るために
Copyright © Benesse Foundation for Children. All rights reserved.


langs: ja ja ja ja ja ja ja ja ja es es es ja ja ja ja de ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja de ja de ja ja es ja ja

text:
日本は、サービスと一般的に言えば、ただという考え方が、市民には定着している。
経営の論理から考えると、それは必ず何かの対価に含まれることになる。
コロナ禍前から、日本でもセルフサービスが定着しつつあった。デフレと言われた時代も長かったので、顧客としてもリーズナブルなサービスを求める声も大きくなりつつあった。
そういう時に、登場するのがセルフサービスである。
例えばビジネスホテル。アメニティが必要な人は、フロントで受け取るようなホテルチェーンも増えてきた。流石にリゾート地であれば興ざめだが、ビジネス目的であれば、これが丁度よい。無駄なものも使わないので、資源の節約にもなる。こういうホテルの朝食も基本的にブッフェ形式で、食器の返却もセルフだ。
私が良く利用する立ち食いソバなどは、食器の返却は、30年ぐらい前からセルフだった。今であれば、コンビニのコーヒーもセルフに近い。
サービスを提供する側の人手不足という背景や、それを埋めているのが新興国の人々であるから、自然とハイサービスの要求は減衰する。以前通りハイサービスを求めるのであれば、料金はしっかり払ってくださいね。ということである。
ちなみに、私の趣味の一つにゴルフがあるが、日本ではキャディが一緒に回ることは少なくなった。もちろん、高級なゴルフ場ではキャディは必須だが、一般的なゴルフ場は選択制か最初からセルである。ゴルフしたことがあれば分かるが、バンカーの整備やクラブを持ち歩くのも自分である。慣れれば全くどうってことはない。
新興国などに比べたら、良く分かるが、日本のサービスはハイレベルだ。セルフが増えてきてもなお、世界ではハイサービスの国である。
コロナ禍になって、一気に非接触が必要になり、セルフも増えた。コロナ禍前に比べると不便に感じる部分はあるが、これも慣れの問題だ。社会的な課題を抱える国の日本が、普通の国として、健全に再生するためには、私はセルフサービスがもっと増えるべきだと思っている。
数年前の本にも書いたが、ECは便利だが、考えようによっては、自分で持って帰れば良いものを、運送代行してもらっている部分が大きい。車に乗せないといけないような大物であれば別だが、本にしても食品にしても、配達に頼るのではなく、自分たちで持って帰る。
(もちろん、シニアや運ぶことが大変な方は例外であるが)
今一度、こういうコロナ禍で配達が当たり前になり過ぎている時に、あるべき姿を見つめなおして、コロナ禍が落ち着いたら、顧客としてハイサービスだけを求めるのではなく、自然体で、自分のことは自分でする。
そうすると、必要以上にサービスに対してナーバスにもならないしモンスタークレーマーも減るだろう。セルフサービスだけど、日本全体はハイサービスという新たな境地を生み出すことを目指したい。


langs: ja ja ja de ja wuu ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja en ja wuu ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja wuu ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja wuu ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja wuu ja ja ja ja ja ja ja ja fi zh ja ja it zh ja ja ja zh ja ja zh de ja ja en de ja ja ja ja ja fi

text:
Google の検索エンジンやSNS のアルゴリズムを解析して、自社の Web サイトやSNSを多くのユーザーの目に留まるようにすることで、広告媒体として機能させるというものです。
僕もこの人みたいになりたいなと思っているうちに、気づいたら会社を登記していました。その時は本当に事業案は全く考えていなかったですね。何も考えずにとりあえず会社を作ったという(笑)
(えっ会社だけ先に作る…?)
すごい人が起業してここまで行ったのだから僕も起業しよう、みたいな。その方は起業して成功しているので、金銭的に豊かでかなりの社会的地位があるにもかかわらず、ただの学生でフラフラしていた僕に対しても対等に接してくださって、この人本当に余裕があるな、すごいなと思って、そこに一番感動しました。
その方との出会いが将来を変えたんですね。
では、事業内容はどのように決めたのですか。
当時の僕は社会経験も一切ない単なる学生だったので、そんな僕が最も社会にインパクトを与えられるのはやはりインターネットしかないと思って、まずインターネットの世界に行こうというのは決めました。
その上で、ネット上に転がっている情報ってすごく大きな力を持っていて、その情報をもとにいろんな意思決定がなされるにもかかわらず、現在も質の低い情報ばかりが流通していると感じていて。僕が本を読んだり専門家に会ったりして手に入れた質の高い情報には、必ず大きな需要があるだろうと。ということで、インターネット上で情報を扱う事業をしようと考えました。
その中で、学生の僕でも質の高い情報にアクセスしやすくて、なおかつ興味を持って取り組める領域を探した結果、教育系に至ったということですね。
起業後の具体的な流れは?
それでは、事業内容が確定した後はどのようにして進めていたのでしょうか。仲間を集めるといった箇所も重要ですよね。
元々、僕と東大同期の矢野で2人で起業したんですけれども、Webマーケティングをしようと思ったらエンジニアが必ず必要なんですよ。だけど僕らは2人ともプログラミングができませんでした。
すると、矢野が「今からプログラミング勉強するわ」って言って、HTMLやCSSも知らない完全にゼロの状態から半年ぐらい死ぬ気で勉強してプログラミングをマスターして、一からサイトを立ち上げてくれました。
ゼロから半年でですか?!すごい!
半年で事業化レベルに到達できる力、欲しいですね
そこは本当に矢野を尊敬します。その間に僕は、事業案や、発信した情報が多くの人の目に留まるためにはどうすれば良いかを考えて、Google の検索結果の順位を決定する解析などをしていたという感じです。
近藤さん(左)、矢野さん(右)
ありがとうございます。その辺りのリサーチや勉強を経て、本格的に事業として打ち出したのは何月頃だったんですか。
3月1日に登記して、5月末に事業を始めました。
いつも、まだそこまでリサーチが進んでない段階で始めて、走りながら考えようみたいな感じです。
サイトも最初はとりあえず見られればいいやみたいな形だったんですけれど、事業を走らせながらだんだんブラッシュアップしていきました。
事業を本格的にスタートした後、はじめの方は広告もそこまで貼られないと思うのですけれど、事業が安定してきた、まとまったお金が入ってきたと感じ始めたのは何月頃のことでしたか。
8月頃です。その日はとある資格の試験日だったのですが、たまたま僕らが書いた記事がバズり、そこでまとまったお金が入ったという感じですね。儲けがどれくらい出るかはざっくりとしか考えていなくて。なぜなら事業って思い通りにいかないものじゃないですか。だからざっくり計算して概ね予想通りかなという感じですね。
Web広告型の事業をするということで、他の事業形態よりも初期費用がかからないと思うのですが、それもありますか。
そうですね、初期投資があまりかからないというのはあります。 ただ、Webメディアはお金をかけないようにしようと思えば全部自力でやってしまえばいいのですが、僕らは「これ絶対成功するな」という確信があったので、細い箇所を思いきり外注して、かなりお金を投入して回していたんです。だから最初の方は月に数百万の赤字でスタートしました。
そんなに?!賭けに出ましたね!
現在ではインターンの方も抱え、人の数も増えてきたと思うのですけれど、初め2人だけで始められたところから、人員を増やしていこうとなったのは何月頃ですか。
最初の方はあまり他の起業家の方などに自分たちのビジネスモデルを知られたくなかったんですよ。なので立ち上げてから4ヶ月、5ヶ月ぐらいは、なかなか人集めができなくて。サークルの後輩を少し誘って始めました。
最初、僕らは自宅で仕事していたんですが、12月1日に初めてオフィスを借りて、そのタイミングで積極的に採用を始めました。立ち上げて半年ぐらいするうちに確実に成功するという確信が持てたし、今から他社が入ってきても追いつけないというとこまで行けたなという感じがあったので、大々的に人を集めることが可能になりました。今はWantedly という採用媒体で人を集めています。
それでは次に、起業後の生活についてお聞かせください。
基本的には、朝9時にオフィスに着いて22時までオフィスにいるという生活を週7でやっています。なのでプライベートは基本的にないですね。主な仕事内容は、複数の事業の戦略立案、関係各社の方との取引のやり取り、インターン生の業務管理などです。
1日にすることが大体30個程ある一方で、捌けるのは20個ぐらいなので、どれだけ頑張っても毎日仕事が溜まっていくという感じですね。
大変ですね…仕事を他の人に委託することではできないのですか。
どんどん委託するようにはしていて、実は既に既存事業の大部分はインターン生に裁量権を与えて統括してもらっています。でも人に任せて仕事が減ると、僕はまた新しいことに着手してしまうので、仕事を減らそうとすればするほど、逆に仕事が増えていく感じですね(笑)。
そうですか(笑)。新しい事業と現在の事業の維持はどちらが大変ですか。
最近だと維持の方が大変だなと思っています。立ち上げた事業がどんどん大きく膨れ上がっていくので色々な所に綻びが出てきたり、細かい部分で強い競合が生まれたりするからですね。
資格Timesの扱う色々な資格のうち、例えば会計士に特化した別のサイトが競合として出てきたりもするので、自社のサービスをより良いものにして、相対的に勝つということをしていますね。
どのようなことをされているんですか?
例えば、実際に会計事務所を運営している方のお話を伺い、そこでいただいた情報を提供したりするなど、競合が真似したくてもできないようなことをする場合が多いですね。
実際に取材するんですね!
学びTimesの方でも、例えば今大変注目を集めているタブレット教材に「スマイルゼミ」というものがありますが、このサービスの評判を知りたい方に対して、「実際にスマイルゼミを購入・利用した生のレビュー記事」を作成することで、ユーザーが本当に知りたい情報を提供しています。
(その記事はこちら:https://manabitimes.jp/education/5)
生の声があると説得力が増しますね。
仕事に関して、ワクワクされることや、逆に「これはしんどい、大変」と思う事はありますか?
楽しいのは、自分の考えた事業が成長していくのを見るのが一番かなと思います。基本的にビジネスの世界は自分が社会に与えたインパクトの大きさが売上という形で可視化されます。僕は結構競争心が強いので、そういう人にとっては向いているかなと感じています。
やはり収入が数値化される時が楽しいですか。
やっぱり勉強みたいなものですね。勉強したら、した分だけ成績が出るじゃないですか。
そうですね。逆に大変なことというのは、今のお話からだと PV や売り上げの数値が減ることかもしれないですけれど、どういった箇所ですか?沢山あると思いますが……
大変な事って言われるとその他全部大変ですけど(笑)、一番はプライベートの時間が本当になくて、24時間365日仕事のことを考えているので、心休まる時間がないということですかね。
あと重要な仕事も人に任せられるようにはなってきたのですが、根幹となる事業計画は基本的に全部僕が作っているので、僕がミスったら会社が死ぬというプレッシャーがありますね。
会社を双肩に担っているのですね
9時から22時まで働いていて、家に帰ってからも頭の中は常に仕事のことを考えているのですか。
お酒が好きなので帰り道に買って帰るんですけれど、飲みながらも大体仕事のことを考えていますし、たまに見るYouTube もビジネス系のものしか見ないですね。
常に「ON」の状態が続く感じですね。
そういう少し大変な生活をしている中で、「やはり起業しない方がよかったなぁ」と感じることはないんですか?
結果論ですけれど、結果として現在、会社がそこそこの規模までは成長できていて、今後これぐらいの規模までは伸びるだろうという確信はあるので、それがあるとどれだけ忙しくても起業してよかったと思います。
途中で大変な時に「これで一旦会社は終わりににしようかな」と考えたことはありますか。
そういうことはあったような気がします。起業して最初の方はかなりきつく、売上も立たず、みたいな状況は結構あったので。でも正直、僕は嫌なことは全部忘れちゃうので覚えてないです(笑)。
話は変わって、近藤さんご自身についても少し伺いたいと思います。
近藤さんが起業をする前の学生生活について、テニスサークルALLDC(アルディック)の代表をやっていらしたと聞きました。代表をしようと思ったのには何か理由などありますか。
基本的にサークルに対しては好印象でしたし、ずっと普通に楽しく過ごしている間にいつのまにか代表になっていたという感じですね。
そうなんですね。起業もされているので、人を率いたりリーダーをすることに興味があるのかなと思いました。
元々目立ちたがり屋で小学校の頃からクラス委員はとりあえず立候補するみたいな性格だったので、代表をするということは僕の中では自然な流れでした。高校の時もテニス部代表だったのでその流れで代表をしていました 。
その他に、大学時代に芸能活動もされていたと伺いましたが、その辺りのお話も詳しくお聞かせください。
ALLDCに入ったのと同じ時期なのですけれど、駒場って渋谷に近いじゃないですか。渋谷ってスカウトマンがめちゃめちゃいるんですよ。歩いているだけでいろんな芸能事務所にスカウトされて、大手の事務所さんに俳優の卵みたいな形で入らせていただいたという形ですね。
活動の内容はどのようなものだったのですか?
月に2、3回ぐらいでレッスンがあり、たまにCM のオーディションを受けるという感じでした。一応1回だけたまたまオーディションに通って CM に出たことがあります。でも、本当に僕は信じられないぐらい演技が下手で、その事務所は俳優主体のスタイルだったので、僕は不適合者ということで一瞬でクビになりましたね(笑)。
芸能事務所に入ってこういうことを達成したい、といったものはありましたか、それとも何となく誘われたから入ったという形ですか。
完全に後者ですね。もともと岐阜県の田舎出身で、岐阜県にスカウトなんてまずこないじゃないですか。スカウトされる事自体が面白かったということと、田舎からすると芸能事務所は憧れで、その中に入ってみたかったというのはあります。
どんなことを考えているの?
それでは近藤さんの考え方について伺いたいのですが、生活している中で大切にしている考え方や行動規範といったものはありますか。
結局会社関連の話になってしまうのですが、「会社の大きさは代表の器の大きさに比例する」という考え方が僕の中にあるので、小さな成功に満足しないでに常に上を目指していきたいというのがまずあります。
その上で、僕らが身を置いているWebマーケティングの業界は「人を騙すような表現やグレーな表現で釣る」みたいなことはかなりできてしまうんですよね。でもそういうのは長続きしないし、それで死んでいった会社もいくつか知っているので、僕らは道を踏み外すような方法には一切手を出さず、真面目に愚直に良いサービスを作っていきたいという信念のようなものはあります。
着実に上を目指すということですね。
会社や事業運営、ご自身における最終的なゴールについてもお聞きしたいです。
まず状況って毎日大きく変化するものだと思うんですよね。なので具体的でかつ長期的な目標は基本的には立てていないです。常に最新の情報を取り入れて、毎日最適なものを積み重ねていくというスタンスでいますね。もちろん目下数ヶ月間の売り上げ目標は立てるのですが、半年以降のことは基本的にわからないと感じですね。
おお!(何かすごく起業家っぽい!)
ただもう少しだけ言うと、すごくざっくりとした目標があって。会社の目標か僕の目標かどちらとも言えませんが、誰の目から見ても明らかで文句のつけようもないぐらい成功したいと思っています。会社が成功することが僕の成功にもなるので、来年には達成したいと思っています。
事業も、そもそも学生として取り組めそうな領域が「Web×教育」だったわけなので、会社の規模が大きくなってできることが増えたら、それ以外の分野を扱うのも全然ありかなと思っています。
最後に、読者の方にに向けて「これだけはしておくべき!」という一言をお願いいたします。
僕はもともと起業しようと思っていたわけではないので、絶対違うのは「起業しろ」ですね(笑)。今これを見ている高校生や大学生の方、皆さんそれぞれの選択をされると思うのですが、1個だけ伝えることがあるとすれば「選択をする際に情報の収集を怠ってはいけない」ということです。
僕が最初マッキンゼーに入りたいと思った時もそうですが、他の選択肢を見ずに頭の中だけで一つに決めてしまっているということは多々ある。でも、どれだけの多くの質の高い情報に触れることができたかによって意思決定の質が決まるんですよ。なので、間違えたくないと思うのであれば、とにかく質の高い情報を全力で探していった方がいいかなと思います 。
近藤さん、今日はありがとうございました!
近藤さんの前向きな考え方、強い向上心に触れて元気が出ますね!また起業に興味のある人は、近藤さんの起業から今に至るまでの流れ、また考え方や生き方に至るまで、参考になる部分があったのではないでしょうか?
そして、皆さんもこの在宅期間を利用しての資格取得に、近藤さんたちの運営する資格Timesを活用してみてはいかがでしょうか?
(Webサイトはこちら:https://shikakutimes.jp/)
最後までお読みいただき、ありがとうございました!
インタビューベンチャー起業
はじめまして! よみです。UmeeTのライターをやっています。よろしければ私の書いた記事を読んでいってください!
TwitterFacebookWebsite
こんな記事も読まれてます
「プログラミングで一番人生が変わったのは、僕ですね。」6万人が利用するProgateの代表・加藤將倫氏をエンジニア集団で直撃!
マネックス証券会長・松本大氏の学生時代に迫る!「東大生よ、エリートたれ」
「日本酒は飲む芸術品」現役東大女子・伊澤優花が語る日本酒ビジネス物語
博報堂×東大が本気出してる件〜超豪華ゲストトーク付き!大学生のためのブランドデザイン・コンテストBranco!ファイナルイベントのお知らせ〜
落ちこぼれだけど起業するJDが意識高い系イベントに潜入してきたぴょん〜the bridge fes 2016〜
UmeeTは「挑戦する東大生」の面白さを発信する、東大発オンラインメディアです。魅力的な東大生・卒業生へのインタビューや海外での留学・休学体験記、自分の研究への愛や、東大生が主催するイベントやスタートアップなど、読み手にとってなにかの指針となるような情報が詰まっております。


langs: ja ja ja ja ja ja ja ja ru ja ja es en en ja ja ja ja ja ja en ja ja ja en en ja ja ja ja ja ja ja ja ja ja pt ja ja ja ja ja en ja ja ja ja ja en ja ja ja ja ja en ja ja ja ja ja ja en ja ja ja en ja ja ja en ja ja ja en ja ja ja ja ja en ja ja ja ja ja en pt ja ja ja ja ja ja en ja ja ja ja ja ja ja en ja ja ja ja ja en ja ja en ja ja ja ja en ja ja ja ja ja ja ja en en en ja fr es en en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja fr ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja

text:
参考:ふるさと納税とは? | ふるさと納税サイト [ふるさとチョイス] | ふるさと納税サイト [ふるさとチョイス]
控除額シミュレーションはこちら。
控除金額シミュレーション | ふるさと納税サイト [ふるさとチョイス] | ふるさと納税サイト [ふるさとチョイス]
上記の寄付金に「プラス2000円」を自己負担することで、対象の自治体から返礼を受け取ることができます。
各自治体によって、返礼品には人気のご当地食材、商品券や工芸品など様々なものがあります。また、納める寄付金の額によって受け取ることができる返礼品も異なってきます。
地域を応援することができる
納めた寄付金はもちろん地域のために使用されます。
「この地域を応援したい!」という観点から寄付先を決めるのも良いかもしれません。
ふるさと納税で注意いただきたいのは、寄付したお金は戻ってくるわけではなく、支払う税金が減税されるということです。
「手続きすれば後で支払ったお金が戻ってくる」と勘違いしている方もいるようですので、「ふるさと納税を行うと税金が減税される」ということを認識した上で手続きを行うようにしてください。
実際にやってみないと「なんとなく面倒そう」と感じてしまう手続き。
ふるさと納税を知っていても約8割の方が実施できていない大きな原因かもしれません。
今回私も初めてのふるさと納税の手続きをふるさとチョイスで行いました。
初期手続きは非常に簡単でネットのみで手続き完了させることができました。(※寄付先の自治体によってはネット手続き出来ない所もあるため、対象の自治体をご確認下さい。)
①税控除上限の寄付金をシミュレーションする
上の方でも書きましたが、個人の所得によって税控除の上限額が決まっています。
寄付金を支払い過ぎて損しないために事前にシミュレーションしておきましょう。
控除額シミュレーションはこちら。
控除金額シミュレーション | ふるさと納税サイト [ふるさとチョイス] | ふるさと納税サイト [ふるさとチョイス]
①で寄付金を決めたら、その額に応じて受け取ることができる返礼品を選択します。
寄付先の自治体によって異なりますが、寄付金に応じて範囲内の返礼品を複数受け取ることも可能です。
仮に5万円寄付する場合、
「5万円寄付相当の返礼品を1品受け取る」ことにしても良いですし、
「3万円寄付相当の返礼品を1品、2万円寄付相当の返礼品を1品受け取る」ようにすることも出来る自治体もあります。
このあたりは自治体によって異なるため、寄付先の自治体をご確認ください。
③返礼品の送付先など必要情報を入力する
②で返礼品を選択したら、このタイミングで返礼品の送付先などの必要情報を入力していきます。ふるさとチョイスでは、「対象の自治体に寄付を決めた理由」や「寄付金の使い道に関する希望」など簡単なアンケートもありました。
また、確定申告の有無によって、この後の手続きが少し変わってきます。今回私は確定申告が必要なかったため、ふるさと納税ワンストップ特例制度を利用しました。
手続き完了後に必要書類を提出する必要がありますので、詳細については以下をご確認ください。
参考:ワンストップ特例制度の申請方法 | ふるさと納税サイト [ふるさとチョイス] | ふるさと納税サイト [ふるさとチョイス]
確定申告を行う方の場合は以下をご確認ください。
参考:意外と簡単!ふるさと納税をした場合の確定申告 | ふるさと納税サイト [ふるさとチョイス] | ふるさと納税サイト [ふるさとチョイス]
③で必要情報を入力したら、自治体へ寄付金を振り込む手続きに進みます。
今回私は、ふるさとチョイスから「Yahoo!公金支払い」によるクレジット払いで手続きを行いました。
ちなみに「Yahoo!公金支払い」については、特に事前登録など行う必要はありませんでした。Yahooのアカウントを持っていてTポイントの連携を済ませている場合は、寄付金にTポイントを使用することも可能です。
これでふるさと納税の初期手続きは完了です。
⑤返礼品と寄付金受領証明書を受け取る
自治体及び返礼品によって届く時期は異なりますが、寄付金支払いから約1カ月ほどで返礼品と寄付金受領証明書が送られてきます。
⑥寄付金控除の手続きを行う
③で選択した「確定申告を行う場合」もしくは「ワンストップ特例制度を利用する場合」に応じて寄付金控除の手続きを行います。
上の方でも書きましたが、寄付したお金は戻ってくるわけではなく、支払う税金が減税されるかたちとなり、翌年度の住民税や所得税から控除されるようになります。
以上がふるさと納税の一連の流れとなります。
今回初めて実施した「ふるさと納税」の手続きについてまとめてみました。
自己負担2000円は掛かりますが、寄付という形で地域を応援することができ、節税に加えて返礼品も受け取ることができるため、メリットはとても大きいと感じました。
手続きも思ってたより簡単に済みましたので、来年も是非実施してみたいと思います。
ふるさと納税が気になっている方はぜひ行ってみるべきだとオススメします。
ふるさと納税はこちらから。
参考:ふるさと納税サイト [ふるさとチョイス] | お礼の品掲載数No.1
pekitarin 2017-11-26 00:28
【ONE PIECE】単行本別の登場人物まとめ記事一覧
【ONE PIECE】単行本別の登場人物まとめ 〜1巻〜
【小説】過去に読んだ米澤穂信作品情報
【お笑い】M-1グランプリ歴代優勝者
優勝回数トップ10 ~相撲の歴史~
« 【ONE PIECE】単行本別の登場人物まとめ … 【ONE PIECE】単行本別の登場人物まとめ … »
id:pekitarin はてなブログPro
継続的な計画による特化型テーマの複合ブログです。
【テーマ】ONE PIECE / 大相撲 / 鹿児島 / お笑い / 本
野球の記録がここにある
pixivFANBOX
【Python】Webスクレイピング ~指定したタグを取得する~
【Python】Webスクレイピング ~HTMLを取得する~
【お手軽ブログ分析】記事評価ツールを作ってみた
【統計】統計検定の概要について
ONE PIECE (78)
スポーツ選手 (30)
Python (17)
ネットビジネス (16)
当サイトの掲載広告について
当サイトは第三者配信の広告サービス「Google Adsense グーグルアドセンス」を利用しています。
広告配信事業者は、ユーザーの興味に応じた広告を表示するためにCookie(クッキー)を使用することがあります。
Cookie(クッキー)を無効にする設定およびGoogleアドセンスに関する詳細は「広告 – ポリシーと規約 – Google」をご覧ください。
当サイトが使用しているアクセス解析ツールについて
当サイトで利用しているGoogleによるアクセス解析ツール「Googleアナリティクス」ではトラフィックデータの収集のためにCookieを使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくはこちら、またはこちらをご覧ください。
当サイトに掲載する情報は記事公表時点の正しいものを提供するよう努めております。ただし、提供している情報、リンク先などにより、いかなる損失や損害などの被害が発生しても当サイトでは責任を負いかねますので、ご了承ください。
リンク先の商品は当サイトが販売しているのではなく、各リンク先店舗での販売となります。購入方法、その他お問い合わせは各店舗までご確認ください。商品購入に関するトラブルに関しては、当サイトでは責任を負いかねますのでご了承ください。
また、当サイトのすべてのコンテンツ(プライバシーポリシー・免責事項を含む)は、予告なしに変更・削除されることがあります。
当サイトに掲載されている情報についての著作権は放棄しておりません。当サイト記事からの引用に関しましては「引用元の明示」によって無償で引用頂けます(必ず引用元記事へのリンクをつけて頂きますようお願いいたします)。ただし、全文転載はお断りいたしております。引用許可範囲についても、事前予告なくこれを変更する事があります。また、当サイトのRSSを利用し、コンテンツをそのまま盗用することも禁止しています。
このサイトへの問い合わせは、以下のメールアドレスへご連絡のほどよろしくお願い致します。尚、迅速な返信を心がけておりますが、事情により返信が遅れる場合がありますので、ご了承ください。
当サイトにお問い合わせ頂いた個人情報は、お問い合わせへの返信対応のみの使用とし他の目的に利用することはございません。


langs: ja en ja en en en en en ja fr en ja en en en en en ja ja ja ja ja ja ja ja ja ja ja ca ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en en ja ja en ja ja en en ja ja pl en

text:
核兵器をつくること、保有すること、使うこと、全てを禁止する「世界の新たな条約」が発行される。つまり、核兵器は違法だということが、世界基準となるのだ。
「そんなのは夢だ、現実的じゃない」と言われてきた”核兵器廃絶”がスタンダードとなる日を迎えるというのに、日本国内も、広島も、なんだか盛り上がりに欠けていると感じていた。
「発効までの1週間をコアに、1ヶ月前から、いろんな人たちと組んでSNS含めた全体的な広報戦略チーム組みたいなぁ〜、核禁条約を知らない人、日本が反対してることを知らない人に知ってもらうのが目的。現段階で考えているのは、核兵器禁止条約発効についてのコメントをしてくれそうな著名人にコンタクトを取って、200字くらいでコメントをもらってカウントダウンで掲載すること。どうかな?」
メッセンジャーグループチャットを立ち上げて、これまで一緒に活動してきた仲間たち(カクワカ広島、議員ウォッチ、ヒバクシャ国際署名キャンペーンに携わる仲間)に提案すると、みんな同じように感じていて、オンラインミーティングをすることに。
ミーティングで決まったことは、以下の4つ。
①特設ページをつくり、ステイトメント、若者たちのメッセージ、著名人メッセージ、ヒバクシャメッセージ、イベント一覧、実行委員会を募って載せる
②著名人のメッセージ +写真、若者たちのメッセージ+写真をカウントダウン投稿していく
③核禁条約について説明したインフォグラフィックを投稿する
④1/22,23に広島で開催される発効記念イベントを動画にして誰でも使えるツールにする
それぞれ担当分けをして、定期的にミーティングをしながらすすめた。
ロゴデザインは、プロの方にお願いしたが、それ以外はメンバーの中にデザインが得意な子たちがいたことで手づくりながらもクオリティの高い発信ができたと思う。
私が主に担当したのは全体進行と、著名人メッセージへの声かけ。元旦からカウントダウンすることが決まり、最低でも22人の人にお願いしなければ・・・。私がお願いできる範囲では、なかなか厳しい。
毎年この TO FUTURE ZINEで、アーティストたちのインタビューを掲載しているGUYさんに協力をお願いすると、「わしもなんかやらんといけんと思うとったんよねー」と快諾してくれた。アジカンごっちさん、ブラフマンTOSHI-LOWさんなど、きっと、私たちからでは応えてもらえなかっただろう人たちからメッセージがもらえてとっても助かった。
さらに、発効まで10日のカウントダウン中、毎日「SUSUME! Talk」と題して、様々なゲストを招いてオンライントークや、zoomイベントを開催し、発効当日は「核兵器禁止条約発効!おめでとzoomパーティー♪」でお祝いをした。
この日にいくつも開催されていた、記念イベントを撮った動画は「核兵器は禁止された」というタイトル検索でYou Tubeで視聴できる。
予定していたことをやりきって、少し落ち着いた2月初旬。
メンバーたちと今後の動きについて話し合った。条約は発効したけれども、核保有国も日本も参加していない。特に日本国内での議論を大きくする為に、これからも続けて行く必要がある。
核問題に興味を持っていて、きっかけさえあれば動く若者は増えていると、このプロジェクトを通して実感した。最近では、カクワカ広島がはじめた国会議員に会って核政策についての考えを聞くプロジェクトが発端となって、長崎県、愛媛県、首都圏での「議員面会プロジェクト」が始動している。
すすめ!核兵器禁止条約プロジェクトは、それらの活動をするメンバーや、新たに関わりたい人が集えるプラットフォームとして機能するようなプロジェクトへと発展することにした。
3月にはオンラインイベント「春のすすめ!フェス〜ソーシャルアクション合同説明会〜」を開催。
次は、8月1日(日)18:00〜22:00「夏のすすめ!フェス〜世界を変える!これが核兵器禁止条約だ!SP〜」を開催予定。
核なき世界への「新しいチャレンジ」は、まだまだ続く。
すすめ!核兵器禁止条約プロジェクト 著名人・若者・ヒバクシャからのメッセージ
前の記事Trtain Of Thought – GOTCH
次の記事Train Of thought – 安彦恵里香
Similar Articles
Train Of Thought – 溝口徹
ToFuture2021
いきなり脱線するけど。ともに可決されてしまった、広島市の平和推進基本条例と、国の土地利用規制法って、思いつきとしては同根じゃねーの?と思ってる。他者を制することに拘泥して、自分を律することを忘れている感じが、いかにもしょぼい。
Train Of Thought – yukaly
ToFuture2021
核兵器禁止条約、核不拡散条約(NPT)、核の傘、核抑止力、北東アジア非核地帯、日米安保、沖縄、フェイクニュース、コロナ、ウイルス、サイバーテロ、安全保障、戦後レジーム、潜在的核保有、プルトニウム45.5トン保有(2019 年)、


langs: ja ca ja ja ja ja ja zh ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en en ja ja ce ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh es pt en en ja ja ce en ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja hi hi ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja hi ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en en en

text:
インフラエンジニアの転職体験談 転職サイトにスカウト登録したらメールが凄いことに | Rpapa WEB
具体的な職務経歴のイメージは?
参考になるか分かりませんが、実際に私が転職サイトへ登録した際に使った文章のイメージを記載します。※ネットワークエンジニアなので専門用語が出てきますが、あしからず。
ポイントは「細かく具体的に書く」です。あなたの経験したことを全て記載するぐらいの感覚で良いと思います。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
X年間にわたり、主に中小企業の拠点間ネットワーク構築に従事
2年目~3年目に掛けては他社に出向し大規模なネットワーク構築に従事
—————————————
20XX年0X月~20XX年0X月
[メンバー数] 30名
・自社システム利用に必要なお客様向けの拠点間ネットワーク構築(VPN)
・リモートアクセス環境(SSL-VPNやIPsec-VPN)の構築
※構築だけでなく、提案、設計、運用、保守と全て経験
※20XX年0X月~20XX年0X月にかけては他社へ出向し
100拠点程度の大規模拠点間WAN構築を経験
・営業向け社内原価見積もりの作成および提案活動
・要件定義、設計、検証
・ネットワーク機器コンフィグレーションの作成
・CE向け作業手順書の作成
・構築作業時のCE統括
・ネットワーク保守業務
Router(Cisco)
L3/L2 Switch (Catalyst)
ネットワーク機器  10台、サーバー  10台
※1案件の平均を記載しております。
—————————————
・ネットワークの基礎的な知識(Layer2,3,4)
・ネットワーク技術を組み合わせ要件通りのネットワークを作る力
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
スカウトメールとスカウト企業の管理をしないと大変です
転職サイトに登録し、職務経歴と希望条件を登録すればスカウトメールが続々と来始めると思います。私の場合は複数の転職サイト経由でスカウトメールを・・・100件ほど頂きました。
一つ一つのメール拝見させて頂いたのですが、「頂いた企業さんの情報や求人内容」その全てを頭で管理する事が出来なかったので、エクセルにまとめて管理していました。
そのエクセルには「企業名」「受信日時」「社員数」「評価・感触(○とか×とか)」「その感触にした理由」などの項目を作り、各企業さんの情報を入力していきました。
その企業に対しての感触(○とか×)を記載する事にしたのは、後ほどフィルタリングを行う事で○が付いた企業のみをより深く調べるというような使い方が出来るからです。
又、その感触を記載した理由を記載しておくことで後になっても理由を思い出す事が出来ます。
評価と感触ってどのように決めていたのか?
・社員数などの分かりやすい基準を満たすか
・インターネット上の口コミサイトでの評価
(転職希望企業の評価を確認するのに転職会議を使う)
・その企業のWebサイトを見て感じた感想
などの情報から、その企業が良いと思ったら「○」そうでないなら「×」をつけます。(人によって基準は違うと思います。)
最終的に3社に絞って面接を開始しました
100社近い企業の中から自分の希望にあった条件の会社を選ぶことで最終的に3社まで絞りました。その3社に対して面接を希望するメールを転職サイト経由で送り面接へ進みました。
その我慢は自分のためになるのか?本当にするべき我慢か考える大切さ
どうも。 最近、株のことばっかり考えてるネットワークエンジニアのアルパパです。 さて最近よく考えることがあります。 それは...
【自伝】インフラエンジニアが転職を決意するまで|20.長い沈黙の末の反省文
長い沈黙の末の反省文 U主任はD係長から退職を強要された。職場の雰囲気は最悪である。 U主任とD係長は前からこのような状況だったかという...
【自伝】インフラエンジニアが転職を決意するまで|23.残業の理由
残業の理由 SE業務をやるようになって残業が多くなったアルパパだが、勤務入力の時にその残業分を素直に申請していた。 自分の仕事が遅...
【自伝】インフラエンジニアが転職を決意するまで|17.終わりの始まりと言うのかもしれない
終わりの始まりと言うのかもしれない 自社の社内チームへ戻ることになったアルパパ。 久しぶりの自社への出社。 相変わらずな社内チームの面...
【自伝】インフラエンジニアが転職を決意するまで|03.社内ニートが二人
社内ニートが二人 部署異動の願いも受けてもらえず、やる気を無くしてしまったアルパパ。 1年目の仕事は単純な事務作業が多い。 様々な申込...
第二新卒の転職理由は必ず明確にする!
新卒で採用された会社を数年で退職した人を第二新卒と言います。 特に、最近では会社の雰囲気が合わなかったり、仕事内容がイメー...
転職を検討している企業の評価は?転職会議で口コミを見よう
上司のような過酷な状況になりたくないと思う人は転職した方が良い
コメントをどうぞ コメントをキャンセル
メールアドレスが公開されることはありません。 * が付いている欄は必須項目です
次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。
このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。
同一ネットワーク(セグメント)内の存在確認はPingとarpをセットにすること 13.17ビュー / 1日 | 2016/05/06 に投稿された
wiresharkでポート番号などを指定したディスプレイフィルタ適用方法 12.67ビュー / 1日 | 2015/07/13 に投稿された
wiresharkのフローグラフでパケットの流れを表示する 9.33ビュー / 1日 | 2016/06/19 に投稿された
パケットキャプチャ用に!ミラーポート対応のネットギア激安ハブに迫る 7.83ビュー / 1日 | 2016/05/29 に投稿された
Chromecast(クロームキャスト)に接続できない時の6つの確認ポイント 7.17ビュー / 1日 | 2015/06/05 に投稿された
就活会議は学校のメールアドレスが無いと登録できない?他の方法は? 7.17ビュー / 1日 | 2016/04/03 に投稿された
APアイソレーションとは?意味を理解して必要に応じて有効/無効にしよう 7ビュー / 1日 | 2015/07/14 に投稿された
見れない人必見!転職会議の口コミを見る2つの方法とは? 6.83ビュー / 1日 | 2015/08/03 に投稿された
Chromecast(クロームキャスト)のMACアドレス確認方法を紹介 6.83ビュー / 1日 | 2016/01/08 に投稿された
tracertの表示が遅い?!オプションを指定して結果表示を早くしよう 4.83ビュー / 1日 | 2017/08/15 に投稿された
卒業式サプライズをする芸能人動画まとめ 4.67ビュー / 1日 | 2016/01/11 に投稿された
通信で使う「コネクション」と「セッション」の言葉の違いとは 4.50ビュー / 1日 | 2016/05/19 に投稿された
ポート設定はオートネゴシエーションか固定設定どちらがいいのか 4.50ビュー / 1日 | 2021/04/28 に投稿された
IPv6 ステートレス自動設定とRS、RAメッセージについてのまとめ 3.83ビュー / 1日 | 2016/07/06 に投稿された
終了するISDNの後継候補「NTTデータコネクト」について調べてみた 3.50ビュー / 1日 | 2016/11/19 に投稿された
CoAPとは?HTTPより軽い?使うメリットについて調べてみた 3.33ビュー / 1日 | 2016/05/19 に投稿された
帯域保証型回線と帯域確保型回線の違いについて 3.17ビュー / 1日 | 2022/05/06 に投稿された
見ず知らずの子とプリパラのトモチケを交換する娘に驚いた話 3.17ビュー / 1日 | 2015/09/06 に投稿された
wiresharkの使い方講座 ~パケットキャプチャの方法とパケットの見方について~ 3ビュー / 1日 | 2015/07/09 に投稿された
綿棒の綿が耳に入ったけど意外な物で取り出せた話 3ビュー / 1日 | 2016/11/18 に投稿された
アルパパの転職体験談です。ブラック会社へ新卒で入社し、転職を決意し無事に「脱出」するまで何があり、何を考えたのかを書いています。※未完
月別アーカイブ 月を選択 2022年5月  (1) 2021年5月  (1) 2021年4月  (3) 2019年3月  (6) 2019年2月  (3) 2018年4月  (4) 2017年11月  (3) 2017年8月  (3) 2017年7月  (1) 2017年6月  (7) 2017年3月  (5) 2017年1月  (11) 2016年12月  (4) 2016年11月  (15) 2016年10月  (5) 2016年9月  (1) 2016年7月  (3) 2016年6月  (5) 2016年5月  (19) 2016年4月  (9) 2016年3月  (4) 2016年2月  (10) 2016年1月  (16) 2015年12月  (27) 2015年11月  (21) 2015年10月  (8) 2015年9月  (14) 2015年8月  (9) 2015年7月  (8) 2015年6月  (13) 2015年5月  (2)
カテゴリー カテゴリーを選択 ASP  (1) AWS  (3) BUMP OF CHICKEN  (1) CCNP  (3) Chromecast  (3) Google  (2) Google-Adsense  (4) Google-Analytics  (6) IPAネットワークスペシャリスト  (16) IPA情報セキュリティスペシャリスト  (7) IPv6  (2) Linux  (6) LPICレベル1  (3) NETGEAR  (3) Office365  (1) Vorkers  (2) Wireshark  (7) 【自伝】転職決意  (25) ウェルスナビ  (1) グルメ  (5) スマフォ  (1) セキュリティ  (2) デカ盛り  (2) ニュース  (7) ネットワーク  (47) ネットワークコマンド  (6) パケットキャプチャ  (9) ビジネス  (7) ブログ  (26) ブログ運営  (28) マクドナルド  (1) メール  (1) リーダー  (2) ルーター  (1) 体のこと  (1) 動画  (3) 周辺機器  (1) 子供グルメ  (4) 就活  (2) 情報処理安全確保支援士  (3) 日記・雑記  (28) 書評  (3) 株  (6) 社会  (1) 社内ニート  (3) 第二新卒  (14) 節約  (1) 紹介したい  (4) 観光  (2) 記事外注  (1) 資格  (10) 資格取得  (9) 転職  (68) 転職会議  (8) 野菜たっぷり外食  (1)
転職経験者の三十路インフラエンジニア(ネットワーク)自分の経験を「人のため」そして「自分のため」に発信することを目的としています。


langs: ja ja ja en ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja fr ja ja ja ja ja ja ja en ja ja ja en

text:
この清燙牛肉湯に、四川省や湖南省という辛旨食文化圏出身の人たちが売っていた辛い味付けの牛ホルモン煮を合体させたものも、牛肉麺の原型のひとつなんだよ。
台湾全土で愛される牛肉麺
こうして台湾南部で生まれた紅焼牛肉麺は、民国50年代中期に台湾北部にも広がるんだ。当時の北部では清燉牛肉麺が主流だったけど、スパイシーな味付けと大きな牛肉が乗った「川味(四川風味)」の牛肉麺はあっという間に大人気に。
ちなみに当時の城中区(現在の総統府のある一帯)では、桃源街のお店は四川風味の紅焼牛肉麺、延平南路のお店は清真の清燉牛肉麺、という風に分かれていたんだって。おもしろいね。


langs: ja ja ja en ja ja ja ja ja ja ja ja en ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja als ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja uk ja ja ja ja ja ja ja ja ja ja

text:
総本宮である香川県の金刀比羅宮と同じく、事比羅神社も境内までは長い石段が続きます。とは言っても、石段の数はそんなに多くはないので、数分もあれば上れてしまいます。※写真は紅葉前のものです
石段の先には鳥居があり、周囲の燃えるように真っ赤なモミジに期待が膨らみます。
鳥居をくぐれば辺り一面の葉が赤や黄色に色づき、まさに今が一番美しい時期だと分かります。事比羅神社の紅葉は、毎年11月下旬頃が見頃です。
社殿の外観は赤色で、小さくて可愛らしい見た目です。
赤色の社殿と周囲の黄色い葉が鮮やかな色彩の写真を生み出します。SNS映えする写真もたくさん撮れそうな場所なので、若い人でも楽しめるスポットだと思います。
空を見上げれば、木漏れ日がさして優しく照らされた黄色い葉が、アーチのように天井を覆っています。
境内には屋根がついた木造の休憩スペースがあります。
この休憩スペースは、肥前浜宿や浜川などが一望できる絶景スポットです。紅葉を一通り楽しんだら、椅子に座って食事や休憩をするのも良さそうです。
今のところ事比羅神社の紅葉はほとんど地元の人しか知らない隠れた名所です。私が撮影に出かけた日は他に誰もおらず、目に入るこの美しい景色を独り占めできると思うと贅沢な気持ちになります。酒蔵通りから徒歩ですぐに行ける距離なので、秋の季節に肥前浜宿に旅行へ来たときに事比羅神社に行かないのは、非常にもったいないことだと感じました。


langs: ja id ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ko ja ja ja ja ja ja nl en ja ja ja ja ja ja ja ja ja en ja en ja en ja en ja en ja ja ja en ja en ja en ja en ja en ja en ja ja ja en ja en ja en ja en ja ja ja en ja en ja en ja en ja ja ja en ja ja ja ja ja en ja en ja en ja en ja ja ja en ja ja ja ja ja ja nl en ja ja ja ja ja ja ja fr ja ja fr ja ja nl ja ja fr ja ja pl en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja nl es es en ja ja fa ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja

text:
つまり、家族として買い出しや炊事洗濯なども行うものです。
認知症の人の世話は大変なため、進んでやりたがる人は少ないでしょう。そのため、施設に入所していない場合、家族が後見人等になると結果的にすべての世話をその後見人等がすることになってしまいがちです。
後見人等を検討する際には、このようなことも十分認識した上で親族の協力が得られるよう、根回しなども必要だということです。
法定後見の場合、最初に報酬が提示された上で後見人が選ばれるわけではありません。
1年間職務を行い、家庭裁判所に報告書を提出する際に「報酬付与の申立て」を行うことで、家庭裁判所が被後見人(本人)の財産額に応じて報酬を決めるもののため、後見人に選ばれるときには報酬がいくらになるかわかりません。
親族の場合は「無報酬」になる可能性もあります(交通費などの実費はもらえます)。
実際には、親の財産管理などを行うために、報酬や交通費をもらう行為を心苦しいと思う後見人等や、後見人等が報酬をもらうのを不服に思う親族も中にはいます。
報酬をもらうか否かは後見人等になる親族の考え方次第ですが、アドバイスする側としては、専門家が後見人等になる場合には報酬がかかること、家庭裁判所が公表している報酬の目安などを参考情報として伝えておくことも大切です。
後見人候補者になる前に
法定後見の申立てをする時には、成年後見制度について次のことを理解してもらうようにしましょう。
本人のために本人の財産を使用する制度であること。
後見人等の職務の範囲は、主に法律行為を行うこと。
介護や家事などの世話は、後見人等の職務でないこと。
交通費などの実費は経費としてもらえること。
財産管理を行う上で不正行為がないことを証明するため、収支を開示する必要があること。
特に親族が後見人等になる場合は、その後見人等だけに介護や家事などの負担が集中しないよう、事前に「後見人の職務」について親族の理解を得ておく必要があります。
また、後見人等に選任されたら、原則辞任はできません。
辞任ができる場合は、後見人自身が認知症になってしまう、転勤等で通うことが困難になってしまうなど正当な理由があり、家庭裁判所の許可がなければなりません。
大変だからといって辞められないことを、後見人等になる人は認識しておく必要があります。
相談者のなかには、後見人等として被後見人のために職務以外の支援もしてきた場合、遺産を多めにもらいたいと思う人もいるでしょう。しかし、いくら頑張ったと主張しても、遺言書がなければそれは難しいものです。
このように、相談者には成年後見制度の概要だけではなく、自分が後見人等になると考えているかどうか、その際の注意点なども伝えられるとよいでしょう。
千葉県松戸市在住。セミナー講師歴16年。相続・終活コンサルタント、行政書士。相続専門の行政書士として実務も行っており、葬儀や墓など供養業界にも詳しいことから、終活や相続に関する一般向けセミナーや企業研修を全国で行っている。 また、テレビやラジオの出演、新聞・雑誌等へのコラム執筆や監修、銀行や互助会(葬祭)向けの教材、著書など多数ある。   ◆相続相談、遺言書作成、おひとりさま準備、相続手続きは、『 明石行政書士事務所 』 へ
コメントは受け付けていません。
« 相続の対策は範囲が広い
シニア世代の相談2|法定後見制度を利用するタイミング »
夫婦でやっておく手続きーおとなの週刊現代Vol8
杉並区で消費生活サポーター向けエンディングノートセミ…
セミナー講師の様子エンディングノートセミナー行政・福祉関係ピックアップ
シニア向け大学-終活講座の様子:流山市ゆうゆう大学(…
セミナー講師の様子終活・老い支度セミナー(全体像)行政・福祉関係
長野県白馬村役場で自分や家族が老いを迎える為の準備セ…
セミナー講師の様子終活・老い支度セミナー(全体像)行政・福祉関係
エンディングノートの監修ー週刊ポストGOLD付録
終活・老い支度セミナー(全体像)
エンディングノートセミナー
おひとりさま準備セミナー
消費者教育・悪質商法などのセミナー
掲載された記事(一覧)
メディア掲載・執筆お知らせ
相続と終活の相談はこちら→明石行政書士事務所にて
終活・相続講座1|起こりうる困りごとを知っておく
女性セブン|改正予定の贈与に関するコメント
大田区消費生活センター主催|エンディングノートセミナ…
セミナー講師の様子エンディングノートセミナー行政・福祉関係
実績豊富なプロが相続・終活に向けて今すべき準備やアプローチ方法を伝授
さっそく問い合わせる さっそく問い合わせる arrow_right
PROFILE/ プロフィール
ABOUT/ 事務所概要
CONTACT/ お問い合わせ
SEMINAR/ 研修・セミナー
◆ 社員・専門職向け/ テーマと概要
◆ お客様・市民向け/ テーマと概要
◆ 講演先実績/ 業種別
◆ 講演先実績/ 地域別
◆ 行った研修テーマ/ 業種別
◆ 行ったセミナーテーマ/ 地域別
◆ セミナー講演の様子
MEDIA/ 著書・執筆・掲載
●メディア掲載・執筆 / 実績一覧
BLOG/ コラム・情報
プライバシーポリシー/特定商取引に基づく記載
Copyright © 2020 明石久美(明石シニアコンサルティング) All rights Reserved.


langs: ja en ja lt ja en ja lt ja ja ja ja ja de ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja ja ja ja ja ja ru ja ja en ja ja ja ja ja ja ja ja pl ja ja ja ja ja ja ja ja ja ja ja ja ja lt ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja zh ja ja lt ja en ja en ja

text:
そのため、今年何度も対戦したことのあるチームに対して、より大きなモチベーションで臨むことができるでしょう。
シーズンを通じてそうであったように、マレーが上手くプレーした場合、スパーズは勝つ可能性がはるかに高くなります。
彼がオフェンスで適切なスポットに到達し、チームメイトを生かして、高いレベルでディフェンスができることは、すべてスパーズの勝利への大きな鍵となるでしょう。
【NBA観戦に最適!楽天モバイル! 】
ペリカンズは1試合あたりの得点で21位、オフェンスレーティングで19位と、スタッツ上ではあまり強力なオフェンスとは言えません。
しかしペリカンズが強力なのはリム周りです。
ペリカンズは、オフェンスリバウンドで3位であり、インサイドの強さが際立ちます。
逆に、ペリカンズはディフェンスリバウンドで24番目にランクされています。
スパーズはオフェンスリバウンドも効果的なチーム(7位)なので、試合中に何人かの選手が絡み優位に勧めることができます。
ポップは他のゲーム要因に応じて、ツインタワーラインアップを使用することがあります。
恐らくヤコブとバナンチュナスがボードバトルを繰り広げます。
昨年のプレイインゲームで当時メンフィスに所属していたバナンチュナスに23得点と23リバウンドを許しました。
これはヤコブにとって特に興味深いマッチアップになることでしょう。
そのため、この試合ではより多くのポイントを獲得する必要がありできると信じています。
3. 最低12本の3Pを決める
数字上では、スパーズが勝つための確かなチャンスを得るには、12本の3Pが必要であることを示唆しています。
スパーズは今年、少なくとも12本の3Pを決めると勝率21-20で.500を超え、そうでないときはわずか13-28でふ。
この数字を達成するために、最高のアウトサイドシューターが必要になります。
ヴァセルは、4月に入ってからアウトサイドシュートが好調で、3P成功率48%という驚異的な数字を叩き出しています。
またケルドンは現在素晴らしいアウトサイドスコアラーになりつつあります。
彼は現在9試合連続で20点ゲームを記録しています。
今季ケルドンが4本以上3Pを決めると、スパーズは9勝5敗です。
彼がもう1度爆発ができれば、サンアントニオが前進し、ペリカンズのシーズンが正式に終了することに大きく貢献することになるでしょう。
昨シーズンのプレーイントーナメントでは若手選手は不調で、ベテランにほとんど頼る場面が目立ちました。
今シーズンはベテランはいません。
昨年の悔しさをバネに若手選手がステップアップして、プレーオフを掴み取ることを期待します。
引用元:Air Alamo
引用画像:San Antonio Spurs Photo Galleries
YouTubeもやっています!
SPURS-GYM Channel
9月16日発売!ヤニス 無一文からNBAの頂点へ
▼カンパしていただけるとすごくモチベーションが上がります!▼
マッツのほしいものリスト
▼ たまにポチっとしていただけると嬉しいです ▼
#サンアントニオ・スパーズ
#GO SPURS GO
ケルドン・ジョンソンデジョンテ・マレー
TwitterFacebookはてブPocketLINEコピー
【NBA】SPURS-GYM
コーヒーギャングはどうやって実現する?
スパーズのベテランガードのパティ・ミルズは、チームの「コーヒーギャング」の伝統を新世代に引き継ぐことを任されていますが、パンデミックの際に彼はどのようにそれを実現するのでしょうか。 チームは最近スパーズのソーシャルメディアアカウント...
オースティン・スパーズのロスターが発表
Gリーグ開幕 スパーズの下部組織であるAustin Spursは2019年のトレーニングキャンプのロスターとスケジュールを発表しました。   シーズンは11月8日が開幕戦です。   ロスターにはサンアントニオ・スパーズの2way...
ロニー「プリモはこれからどんどん良くなる」
スパーズのルーキー、ジョシュ・プリモはサンアントニオでルーキーながらNBAの32試合に出場しています。 チームメイトのロニー・ウォーカー4世はプリモのことを気に入っているようです。 プリモはサンアントニオで1試合平均15.7分...
パートルは飛躍の年となるか?似ている選手とは?
スパーズ唯一の純正センター スパーズはギアをシフトしています。このチームは、多才なガード陣を要しており、ゲームペースを上げる準備ができています。 スパーズ2年目のセンター、ヤコブ・パートルはまさにそれを行うのを助けることができます。 ...
NBA2K22のレーティングが発表!スパーズの選手は?
NBAのテレビゲームシリーズで世界で最も人気があるNBA2Kの最新版が間もなく発売される予定です。 プレーヤーのレーティングが徐々に分かってきました。 NBA2K22の発売に先立ち、 スパーズの何人かの選手のレーティングの情報...
デジョンテ・マレーの膝が完治!
Dejounte is Back ‼ スパーズのPG、DマレーがTwitterで昨年ケガした右ひざが完治したことを報告しました。 Dマレーは昨シーズン開幕前に右ひざACLを損傷する大けがを負い、シーズン全休となりました。 I Jus...


langs: ja en ja zh ja en en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja en en ja ja ja ja ja ja fr en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja zh ja ja ja ja ja ja ja ja ja ja ja ja en ja de ja ru en ja zh en ja de ja ja zh it ja de ja ja en en

text:
docomo ARROWS NX F-06E を買いました — F06E の大きさ比較 │ ALPHA LABEL
docomo ARROWS NX F-06E を手にして、真っ先に感じることは「大きい」ということ。
スペック表によると、『高さ 139mm × 幅 70mm × 厚さ 9.9mm(最厚部 約 10.8mm)』、ディスプレイサイズは約 5.2 インチとのここと。
XPERIA SO-01C の大きさは『高さ 125mm × 幅 63mm × 厚さ 10.9mm(最薄部 約8.7mm)』
XPERIA は端末下のボタンの分、数値上の熱さがあるが、全体的には ARROWS NX の方が大きい。
ARROWS NX F-06E と XPERIA SO-01C を重ねて見ると、大きさは一目瞭然。
もう一つ、手元にあった iPod Classic と大きさを比較。
iPod Classic の大きさは「高さ 103.5 mm × 幅 61.8 mm × 厚さ 10.5 mm」。
厚さに関しては、あまり ARROWS NX と変わらない。
重ねて見ると、iPod Classic が ARROWS NX F-06E の画面内に収まってしまった。
iPod が画面の大きさをあまり必要としないものとはいえ、ちょっとビックリ。
やっぱり…すごく…大きいです…!!
ここまで大きいと、片手で操作しづらいと思って敬遠しがちですが、その点は、いろんな工夫がなされてます。その工夫については改めてご紹介します。
そして、大きい端末でも実際に1週間使ってみると、あっさりと慣れてしまい、それまでの端末を使うと「画面小さッ!狭ッ!!」と感じてしまうので不思議です。
スマートフォンもいいお値段がしますし、1度買うと2年はお付き合いするものになるのですが、ARROWS NX F-06E はこれからの2年間、十分に力強いパートナーになってくれる気がしています。
使いこなしていくのがとても楽しみです。
クリスマスプレゼントを両親に贈りました 2009.12.16
もうすぐクリスマスということで、ちょっと早めですが実家の両親にクリスマスプレゼントを贈りました。 プレゼントの中身は、ユニクロ「ヒートテックインナー」[…]
MacBook Pro に外付けモニタ(+a)をつけてパワーアップさせた 2009.12.14
これまで私のメイン制作環境は「MacBook Pro 15インチ」というものでした。 Photoshop や Dreamweaver なども問題なく動[…]
イー・モバイル「Pocket WiFi」(D25HW)を契約した 2009.12.15
仕事でクライアント先に出向いて打ち合わせなどを行うことがありますが、今まで携帯用のデータ通信機器を持っていませんでした。 今までは Yahoo!BB […]
ビール祭りで飲んでいたら台湾旅行に行くことになった件
[読書メモ]『なぜ、あなたの話はつまらないのか?』
[読書メモ]『一流の達成力』
2017年のJ2で #DAZN週間ベスト5セーブ に最も多くランクインしているのは誰か
Amazon Fire TV Stick を買ったら #DAZN だけでなく他のビデオコンテンツライフも充実してすごーい!たーのしー!
映画『オール・ユー・ニード・イズ・キル』を観てきた に 笑う社会人の生活 より
めちゃイケのデブエット企画「ガリタ食堂」で紹介された18店 に 横浜ブログ より
イヴの深夜の DJ okadada LIVE を盛り上げた有名人Twitterユーザー に marbleのこと(3) | marble より
近い将来お金の価値がなくなる!? お金だけでは満たされない欲求について考える に モチベーションが大切 | ネット塾ジャーナル より
糖尿病と診断されてから1ヶ月が経ちました に ヨハネ より
docomo ARROWS NX F-06
docomo ARROWS-NX (F-02G) レビュー
docomo PRIME series F-01A レビュー
docomo PRIME series F-03A レビュー
docomo SMART series F-04A レビュー
docomo STYLE series F-02A レビュー
Eye-Fiカードレビュー
Movable Type
ThinkPad SL500 レビュー
Thinkpad X100e レビュー
ネットショップのデザイン
WordPress.org
お買い物カテゴリの最新記事
Amazon Fire TV Stick を買ったら #DAZN だけでなく他のビデオコンテンツライフも充実してすごーい!たーのしー!
ARROWS NX, F-06E,
docomo ARROWS NX F-06E デザインをチェック —F-06E は見た目や触り心地もイイ
ARROWS NX, F-06E,
docomo ARROWS NX F-06E を買いました — F06E の大きさ比較
マイクロウェーブヒートプレート,
レンジで3分チンするだけで手軽に焼き魚ができる「マイクロウェーブヒートプレート」を買いました
MacBook Pro Retina ディスプレイモデル 13インチを買いました
軽くて丈夫で運びやすいスーツケース「アントラー・リクイス」
Back to Top
© Copyright 2022 ALPHA LABEL. ALPHA LABEL by FIT-Web Create. Powered by WordPress.


langs: ja ja en ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja zh ja zh ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja zh ja ja ja zh ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en en id ja ja ja ja ja en

text:
このような場合に用いられる実験計画として「Plakett-Burman計画」があります。Plakett-Burman計画は、2水準の実験計画で、Robin L.PlackettとJ.P.Burmanによって提案されました。主効果のみを検出し、実験数が少ないことが利点で、スクリーニングによく用いられます。
Plakett-Burman計画の実験数(サンプル数)は、設計変数の数よりも1以上大きい最小の4の倍数になります。今回のデモ問題では、サンプル数=16です。
サンプル数16のPlakett-Burman計画の表を示します。見方は直交表と同じで、縦にサンプルNo.が並び、横に設計変数を割り付ける列が並びます。そして、表の要素は設計変数の水準を意味します。
サンプル=16のPlakett-Burman計画
Plakett-Burman計画による実験計画の作成には、R(統計解析向けのプログラミング言語)のライブラリであるFrF2を使用しました。プログラミングは本記事のスコープ外なので詳細は記載しませんが、数理設計では必須のスキルです。RのほかにはPythonがよく使われます。
デモ問題のスクリーニング実験計画は以下のようになりました。設計変数は12個なのですべての列は使いません。
スクリーニング実験計画
なお、水準の並びが先の表と違うのは、Rでの実験計画の生成の際に、実験順番のランダム化のオプションが入っていたためです。
スクリーニング実験計画に基づき、OpenRocketでパラメータを調整して作成した16個のサンプルで飛翔シミュレーションを行いました。結果は以下の通りになりました。
実験データを対象に要因効果図を作成します。
手順はロバストパラメータ設計でやったときと全く同じです。各設計変数の各水準平均値を計算すればよいのでした。
要因効果図は次のようになりました。
設計変数のスクリーニング
要因効果図中の各線の縦方向の幅は、その設計変数の影響度の大きさを表すことは以前述べたとおりです。それに従うと、影響の大きそうな設計変数は、\(x_1, x_2, x_3, x_9, x_{12}\)になりそうです。
\(x_8\)も\(x_9\)に近いのですが、そう考えてしまってはキリがありません。スクリーニングの選択に明確な正解はありません。今回は、\(x_1, x_2, x_3, x_9, x_{12}\)を残す(曲面フィッティングに用いる)ことにします。目安としていた4つより1つ多いですが、これくらいなら良しとしましょう。
一方、曲面フィッティングに用いない残りの設計変数は、最高高度が高くなる水準で固定します。
スクリーニング後の設計変数
なお、スクリーニングする設計変数の選択には、上記の要因効果図を視覚的に見て判断するほか、「分散分析」という手法で判断することもあります。これについては、本記事では説明を省略します。
スクリーニング実験の要因効果図から、「各設計変数において最高高度が高くなる水準」を選択したサンプルにて飛翔シミュレーションを行ってみました。
各設計変数において最高高度が高くなる水準
最高高度は、77.8mを示しています。調整前(サンプルファイル)の最高高度が50.5mだったので、これだけでもかなり性能が改善されています。この結果は、次回以降の応答曲面法による最適化における「ベンチマーク」となります。
応答曲面法を本格的に適用する前に、影響の大きい設計変数を絞り込むためのスクリーニングについて説明をしました。
なお、これは応答曲面法のみならず、様々なシーンで使うことのできる手法です。
次回は、曲面フィッティングのための実験について説明をします。
多目的最適化問題(第五回)
多目的最適化問題(第四回)
多目的最適化問題(第三回)
多目的最適化問題(第二回)
多目的最適化問題(第一回)
応答曲面法による最適化設計(第五回)
応答曲面法による最適化設計(第四回)
応答曲面法による最適化設計(第二回)
応答曲面法による最適化設計(第一回)
ロバストパラメータ設計(第五回)
OpenRocketPlakett-Burman計画スクリーニングモデルロケット応答曲面法数理設計最適化設計要因効果図
応答曲面法による最適化設計(第二回)
応答曲面法による最適化設計(第四回)
多目的最適化問題(第五回)
NSGA-Ⅱによるパレートフロントの求解
多目的最適化問題(第四回)
遺伝的アルゴリズムについて
多目的最適化問題(第三回)
RBFネットワークによる応答曲面法(後半)
多目的最適化問題(第二回)
RBFネットワークによる応答曲面法(前半)
多目的最適化問題(第一回)
パレート解とパレートフロント
応答曲面法による最適化設計(第五回)
曲面フィッティングと最適解探索
応答曲面法による最適化設計(第四回)
応答曲面法による最適化設計(第三回)
応答曲面法による最適化設計(第二回)
応答曲面法による最適化設計(第一回)
Copyright © TECHNO OH All Rights Reserved.
Powered by WordPress with Lightning Theme & VK All in One Expansion Unit by Vektor,Inc. technology.


langs: ja ja ja ja ja ja ja ja de ja en ja en en en en ja ja ja ja ja ja ja ja de ja en ja en en en en ja ja ja ja ja ja ja ja ja ja ja ja ja en ja de ja en ja en en en en ja ja ja en ja en ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja en ja ja ja de tg en ja en en en en ja ja ja ja de ja en ja en en en en ja ja ja ja ja fr en en ja ja ja ja ja ja es ja ja ja en ja ja ja en ja ja ja zh zh ja en ja ja ja zh ja ja ja ko

text:
つきましては以下日程にて内覧会を行いますので、ご希望の方は以下までご連絡下さい。
9月18日(日)10:00~16:00 ごろまで
9月21日(水)13:00~16:00 ごろまで
埼玉県上尾市(最寄駅:JR「上尾駅」より徒歩約20分)
一般の方(家づくりをご検討中の方)/専門家(建築関係者)/学生さん
ご希望の方は、以下アドレスまでご連絡下さい。
折返しご案内と申込みフォームのリンクをお送りします。
info@riotadesign.com (担当:関本/今村)
また引渡し後の住宅ですので、小さなお子様をお連れの方はご夫婦で交代でご覧になるか、抱っこひもなどをお使いになるなど十分ご注意の上ご覧下さい。
22. 06 / 19
「空の家」限定内覧会のお知らせ
> OPENHOUSE
以前本ブログでも、リオタデザインが設計した「空の家」が売りに出されているという情報を共有させて頂きました。
○リオタデザインブログ|「空の家」が売りに出されます
https://www.riotadesign.com/blog/220503.html
○「空の家」|建築家住宅手帖・紹介記事
https://archi-techo.com/architects/15
こちらについてですが、建て主さんのご厚意により、建築家住宅手帖さんの主催で限定内覧会を実施させて頂くことになりました。建て前としては本住宅のご購入検討者さま向けのものではあるのですが、本ブログをご覧になり、もし内覧を希望する方がいらっしゃいましたら、購入検討者以外の方(建築関係者・一般の方)もご見学頂くことが可能です。私(関本)も現地にてご案内致します。
内覧希望の方は、以下の要領をお読み頂き希望する時間帯をご連絡下さい。希望者多数の場合は、時間帯によっては早期に締め切る可能性もありますのでどうかご了承下さい。
■所在地:埼玉県川越市藤間 周辺
※詳細な住所はご参加表明頂いた方にご連絡致します。
※最寄り駅:東武東上線新河岸駅より徒歩約9分
7月3日(日)|10時・11時・13時・14時・15時 の全5回にて事前予約制
※お申し込み時に、できましたら希望時間帯を第2希望までお知らせ下さい。
※同時間帯に人数が集中した場合は、ご調整をお願いすることが御座います。
内覧ご希望の方は、以下アドレス宛にご連絡下さい。
info@riotadesign.com (担当:関本)
所在地などの詳細情報は、追って建築家住宅手帖(担当:佐竹氏)よりお送りさせて頂きます。
■今回の限定内覧会について [建築家住宅手帖より]
「建築家住宅手帖」 (https://archi-techo.com/) は建築家が設計した住宅を専門に、その価値を伝え次の方につなげる不動産ポータルサイトです。
良質な建築家住宅が、一般の不動産市場の中で、なかなかうまく継承されていない現状を変えるため、建築家住宅のすばらしさを伝えられるように、きちんと建築の価値を理解し、大切にお使いいただける方に引き継がれるように、日夜取り組んでいます。
その活動の中で、リオタデザイン・関本竜太氏設計の「空の家」と出会い、私共が運営します、建築家住宅手帖で現在販売しております。(価格3,100万円)。詳細は下記サイトにてご覧ください。
https://archi-techo.com/architects/15
約15年前に竣工し、現売主様が大切に住んできましたが、ご家庭の事情で売却することになり、このたび売主様のご厚意で、建築家住宅手帖主催で限定内覧会をさせていただけることになりました。また、もし周りにご購入を検討出来そうな方いましたらぜひともお声掛け頂ければ幸いです。なにとぞご検討のほど、よろしくお願い申し上げます。
建築家住宅手帖・佐竹雄太
[Gallery] 撮影:千葉正人(2022.3撮影)
22. 04 / 14
> OPENHOUSE
昨日は「石神井台の家」に加藤雅康さんのアトリエの皆さんをご案内。オープンハウスではたくさんの方に見ていただきたいという思いに反して、いらした方に十分に対応できないという悩みがいつも発生します。先週末は手薄な対応で申し訳ありませんでした。
今回は個別案内だったので、じっくりとご案内できたのと、意見交換もできて有意義な時間でした。たくさんの方はご案内できませんが、お互い得るものは大きいような気がします。加藤さん、足をお運びくださりありがとうございました。今後も個別案内を希望される方はこっそりお申し出ください。(こちらのスケジュール次第ですが、、)
先週末にはまだまだだったアオダモも、ここ数日の陽気で一気に新緑が芽吹いてきました!
22. 04 / 10
「石神井台の家」オープンハウス終了!
> OPENHOUSE
この土日で開催させて頂いた「石神井台の家」のオープンハウスは、無事終了させて頂きました。2日間に亘ってとても良い天気で、気温も小春日和を通り越してちょっと汗ばむほど。2階の角に設けたインナーテラスは大人気のスポットとなっていました。
石神井台の家は、ビルトインガレージを設けた三層構成の住宅です。南側に隣家が迫ることから、リビング空間は2階に持ち上げ、光をトップライトやインナーテラスから補っています。唯一の眺望の抜けが獲得出来る南西側の角に屋根と網戸のあるインナーテラスを設けました。これからの季節、このテラスは大活躍しそうです。
リビングダイニング空間は、けして広くはない空間ながら、可変収納によって各領域をゆるやかにつなぎ、実際の面積以上にひろがりや奥行きが感じられるような作りとしています。
この日は計画進行中の建て主さんや、いつも来て下さる同業の仲間たちに加え、私の目標とする建築家の先輩方にも多くお越し頂きコメントなどを頂けたことは、大いに励みになりました。皆さま、足をお運び下さいまして誠にありがとうございました!