元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2018/03/21

Amazonで本を注文したら届かなかった話の顛末


14年ほどAmazonユーザなわけで、年間で50〜100件ほどAmazonさんにお世話になっているくらいの利用頻度でしたが、初めて注文したものが届かないといった事案が発生しました。


事の流れは、3/10に本を注文し、クレジットカードで決済しました。で、配送予定日は3/11となっていたんですね。

で、ハッと気付くと3/12。そういえば注文した本がまだ届かないな、と。運送中に迷子にでもなったかなぁ、と。


f:id:rx7:20180321163634p:image:w480

Amazonの注文履歴で見るとこんな感じ。


f:id:rx7:20180321163635p:image:w480

配送状況を確認すると、どうも集荷されたところで停まっている気配。なんかおかしい。

まぁ、急いでいたわけでもなかったので、もうちょっと待つか、と待ってみることに。


で、結局その翌日の3/13夜になってもステータスが変わらなかったため、深夜(3/14)に twitter で上記をツイート。


すると、Amazonヘルプの公式アカウントから上記の Reply がすぐに来ました。

ふむ、配送業者に確認とな。


f:id:rx7:20180321163636p:image:w480

Amazonの注文履歴から、お問い合わせ番号(今回は日本郵便さんだった)が確認できるので、追跡するとやはり「引受」から進んでいないことがわかる。

ならばと、翌朝、TELで問い合わせてみようと思ったのですが、思うように時間が取れなかったので、朝の通勤電車の中で、日本郵便さんの事故調査依頼からリクエストを出そうと思いました。


郵便物等が届かなかった、中身がなくなっていた、知らないうちに開封されていた、著しく遅れて配達された場合、調査のお申出はこちらから受付を行い、調査に関係する郵便局に送付いたします。


で、通勤電車の時間で上記からリクエストを出そうと思ったのですが、上記リンク先を見てもらえばわかるのですが、差出人の情報を結構細かく入力する必要があるのですね。

発送元のAmazonさんの住所や担当者名や電話番号を入力する必要があるのですが、そんなの調べても出てこないし知らんがな、、、と。


よくよく考えると、今回の件は配送業者の過失かもしれないけど、品物が到着するまで、Amazonさんが面倒みるべきだよなと思い、Amazonさんの方で調査してもらうべく、下記リンク先の問い合わせフォームから、これまで経緯を指定のフォーマットにあわせて簡潔に記載し、送信。


1. 注文番号: ********

2. (わかる場合)配送業者名: 日本郵便

3. (わかる場合)お問い合わせ伝票番号: ********

4. お問い合わせ内容:
3/11がお届け予定日ではあるが、3/14現在も手元に届かない。
配送状況を確認しても、品物が配送に向かっている形跡がない。

・・・すると、10分くらいで以下の返事が返ってきました。


Amazon.co.jpにお問い合わせいただき、ありがとうございます。

このたびは、ご注文商品がお手元に届いていない件について、ご迷惑をおかけしておりますことをお詫びいたします。

商品の配送状況をお調べしたところ、配達予定日は2018年3月11日を確認いたしました。今まで商品はお客様のお手元に届いておらず、配達中に何らかのトラブルが生じた可能性があります。

つきましては、とりあえずまずご連絡いただいた商品をお届けするよう手配いたしました。新しい注文番号は#********で、お届け予定日は2018年3月15日です。商品を発送しだい、Eメールでご連絡いたします。万が一、最初に発送した商品と今回手配した商品を両方ともお受け取りいただいた場合は、いずれか一方の商品(未使用で未開封のもの)を着払いで返送をお願いいたします。

本件の対応について、金銭の問題では無いことは重々承知しておりますが、当サイトがご迷惑をおかけしているにも関わらず、このまま何もご提案しないというのは非常に心苦しい限りです。ご迷惑をおかけしたお詫びとしてはささやかですが、500円分のクーポンを並河様のアカウントに登録させていただきました。

・・・・・以下省略・・・・

対応がマニュアル化されているのかと思いますが、クーポンの補填云々はともかくとして、到着予定日から遅延して届いていない状況なので、まず同一商品を取り急ぎ発送しますよ、という対応はベターだよなと感心しました。


そして、その本は、その翌日の3/15に無事に到着した次第です。


それから6日が経ちましたが、結局、最初に発送された方の本は、手元に届きませんし、日本郵便さんの追跡ページを見ても特に動きはありません。発送の事故調査については、Amazonさんと日本郵便さんの間でやってもらえれば良いと思いますし、こういうケースに遭遇した際は、素直に発送元に問い合わせるのが一番だよなとは思いました。


それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


2018/02/16

デブサミ2018「Kubernetesを用いた最強のマイクロサービス環境をGKEで実現しよう」講演メモ #devsumi


Googleのパワーを強く感じられるセッション。さすがでございました。そのセッションのメモでございます。


  • 福田 潔 氏
    • Google Cloud Japan
    • Customer Engineer
  • GKE = Google kubernetes Engine

他のクラウドと比べてGoogleが勝っている点3つ

  • ビッグデータ関連での利用
  • ML/AIでの利用
  • コンテナの利用

kubecon 2017 keynote => 「kubectl is the new ssh...」

  • kubernetesの世界では、低レイヤを気にしなくてよくなる
  • kubectlは、これからのエンジニア全員が覚えるべきコマンドである

なぜkubernetesが注目されるのか

  • VM => コンテナ => コンテナオーケストレータ
    • アプリケーションのコンテナ化が進んでいる
  • モダンアプリケーションのインフラとして

コンテナオーケストレータ

  • Dockerだけではできないこと
    • 複数のノードに対するコンテナのデプロイは?
    • ノード障害が発生した場合は?
    • コンテナ障害は?
    • アップデートは?

モダンアプリケーション

  • デジタル空間でのビジネスが当たり前になっているので、ネットを通じて顧客接点となるアプリは非常に重要
  • 使いにくいアプリは顧客獲得機会の損失を意味する
  • 要件
    • ユーザビリティ、24/7、アジリティ、性能、マルチデバイス
  • それを支える技術要素
    • 自己修復能力、モジュール化、スケール、リリースパイプライン、Blue/Green、カナリアデプロイ、ロールバック、モニタリング
  • これらをkubernetesは機能としてほぼ持っている

kubernetesとは

  • クーバネティス
  • ギリシャ語で「操舵手」「統治者」といった語が語源
  • コンテナをどこで実行するのかを管理
  • Googleの社内システムからインスピレーション
  • 100%オープンソース
    • 様々な企業が開発に携わっている
  • Write Once Run Anywhere
  • 複数のコンテナランタイムをサポート

デファクトスタンダードへ

  • MSとAWSがkubernetesに対応した
  • 3大クラウドベンダ全てがkubernetesにコミットしている
  • CNCFによって32個の認証プラットフォームを認定

Google kubernetes Engine (GKE)

  • GCP上で動作するマネージドkubernetes
  • 2014年に登場
  • アルファクラスタ機能
  • Zero-Opsクラスタを目指す
    • GKEのランタイムはGCEで出来ている
    • GCEにSSHする必要はない = VMは気にしなくて良い
  • 特徴
    • 簡単 (Simple)
    • 信頼性が高い (Reliable)
    • 効率性 (Efficient)
    • GCP各サービスとの統合 (Integrate)
  • クラスタはgcloudコマンドかGUIコンソールから、4〜5分で作成可能
  • クラスタへの接続はGUIコンソールから案内される
    • 5分後にはkubectlが実行できる

クラスタのアップグレード

  • kubernetesはおよそ3ヶ月に1度マイナーバージョンアップ
  • マスタとノード、両方のバージョンを気にする必要がある
  • マスタは自動でアップグレードされる
  • アップグレードスケジュールは、Release Noteに公開

ノードの自動アップグレード

  • 管理オーバーヘッドが少なくなる
  • セキュリティの強化
  • 新しい機能へのアクセス
  • 設定は、コマンドかGUIでフラグをつけるだけ

メンテナンスウィンドウ

  • 自動アップグレードのタイミングを制御できるように、マスタ・ノードともに特定の曜日、4時間単位で設定が可能

マスターのearly upgrade

  • 自動アップグレードを待たず、いち早くアップグレードさせることも可能
  • 手動でコマンドを実行する感じ

ノードのヘルスチェック・自動修復

  • マスターはノードのヘルスチェックを10秒間隔で行なっている
  • 継続的にヘルスチェックを行い、長時間(10分前後)ヘルスチェックに失敗すると修復プロセスを開始する(COSを洗濯した場合)
  • マニュアルでヘルスチェック・修復させることもできる

マルチゾーンクラスタ

  • デフォルトでは指定したゾーンに対してクラスタマスターとノードが作成される
  • 追加のゾーンを指定することもできる
    • 新規作成時や既存クラスタに設定可能

リージョナルクラスタ

  • ノードだけではなく、マスタも複数ゾーンに分散できる
    • マスタも冗長化できる
    • ただしまだベータ扱い
  • GKEでは、現状マスタには課金されないので、使えるなら美味しそう

COS = Container-Optimized OS

  • OSイメージの選択肢はCOSまたはUbuntu
  • COS:Docker利用に最適かされた軽量OS

GKEにおけるスケール戦略

  • ポッドレベル (kubernetes)
    • SO(スケールアウト)はPod数を制御(HPA)、SU(スケールアップ)はPodに対するリソース割り当てを制御(VPA)
  • クラスタレベル (GKE)
    • SOはNode数を制御(クラスタオートスケーラ)、SUはNodeのリソース割り当て(インスタンスタイプ)を変更
  • クラスタサイズの変更はコマンドで簡単にできる
  • クラスタオートスケーラでは、同じ種類のノードがスケールしていく(ノードプールに設定されたノードテンプレートが使用される)

VMインスタンスタイプの変更

  • 既存インスタンスを無停止で変更することはできない
  • 新しいノードプールを作成し、そのプールに既存のワークロードを移行する
  • ダウンタイムなしでワークロードを移行することも可能

プリエンプティブルVM

  • 中断される可能性がある
  • 非常に安価に利用可能
  • 任意のマシンタイプ
  • ワークロードによっては、VMのコストを大幅に下げることもできる
  • 作り方はフラグをつけるだけ

GKEにおけるGCPの役割

  • GKEクラスタの実行基盤
    • ノード => GCE、永続ディスク
    • ノードプール => Instance Group
    • Service/Ingress => TCP/UDP/HTTP(s) LB
    • VPC
  • アドンコンポーネントをマネージメントサービスとして提供
    • データストア => cloud spanner, Cloud Datastore, Cloud SQL
    • DWH => BigQuery
    • メッセージング => Cloud PubSub
    • 運用管理
    • CI/CD

メルカリ導入事例

「ロードバランサとGKEが導入の決め手」


GCPのロードバランサ

  • アプリケーションフロントエンドは強力なLBが必要
  • グローバル負荷分散:クロスリージョン フェイルオーバー
    • リージョンがダウンしても別リージョンにルーティングしてくれる
  • Googleのグローバルインフラ
    • LBはエッジで動いていて負荷分散している
    • 世界各地にエッジポイントが存在する
    • エッジ + バックボーン = 低レイテンシ = 優れたUX

デブサミ2018「インフラチームからSREへ〜メルカリを支える新しいインフラのあり方」講演メモ #devsumi


楽しみにしていた kazeburo 先生のセッション。

電車が遅れていたおかげで間に合わないかと思ったけど、自己紹介が始まったところで、なんとか滑り込み。

メモを書いたので貼り付けておきます。


自己紹介

  • 〜2006 京都のスタートアップ
  • 2006〜 mixi
  • 2010〜 Livedoor(NHN, Line)
  • 2015〜 Mercari

SREとの出会い

  • インフラエンジニア?
    • mixi時代は「アプリ運用チーム」
      • インフラチームは別で存在
      • DCチームが用意したサーバの能力を目一杯引き出す
      • アプリチームが開発したコードを最大限能力を引き出す
  • オペレーションエンジニア?
    • オペレーション(ルーチンワーク)と捉える人も多い
  • SREとの出会い
    • 2012/7にIRCで友人から教えてもらう
    • Googleの巨大なインフラとサービスの稼働・安定性を担保するチームがSRE
    • 2015/11 メルカリにてチーム名として提案

メルカリについて

  • 国内最大級のフリマアプリ
  • 3分で簡単に出品
  • 安心安全な決済・取引
    • エスクロー、匿名配送
  • 米国・英国でも展開
  • KPI
    • ダウンロード数:1億
    • 出品数:1日100万品以上
    • GMV(流通総額):月間100億以上

インフラストラクチャについて

  • マルチクラウド構成
    • JPはさくらインターネット、USはAWS、UKはGCP
    • さらにJP・USではGCPを組み合わせてマイクロサービスの基盤に
  • DNSはRoute53
  • CDNはAkamai、Fastly、ImageFluxなど
  • マイクロサービス基盤
    • 既存API(モノリスAPI)をラップするAPI Gatewayを開発し、GCP(GKE)で構築

改めてSREとは

  • SREとは
    • システム管理とサービス運用の方法論としてGoogleの運用チームを率いていたBen Treynorが提唱

GoogleのSRE

  • GoogleのSREには、ソフトウェアエンジニアリングに加え、システム・運用の能力が求められる
    • ソフトウェアエンジニアリングは「自動化」に特に注力
    • SREの人数はサービスの規模に比例させない(Googleの規模においても実現できない)
    • 「トイル」の撲滅
  • 業務時間の50%はソフトウェアエンジニアリングを行う
    • 自動化(自律化)、信頼性向上にあてる
  • SLA、エラーバジェットによる開発者の利害調整
    • 開発者チームと可用性の目標をサービスごとに設定
    • エラーバジェット内にあるときは開発者は積極的にリリース
    • 予算を超える場合は、信頼性回復のための開発が求められる

日本国内でのSRE

  • 2015/11 メルカリ技術blogでSREを紹介
  • Retty、サイボウズ、Cookpad、Mixi、はてななどWeb企業中心にSREの採用が進む
  • SRE Tech Talk開催
  • 書籍
    • オライリー「SREサイトリライアビリティエンジニアリング」

メルカリSRE

  • 2015/11 インフラチームからSREに改称
    • お客様に長く使ってもらえるには「いつでも快適に安全に使える」が重要
    • サービスパフォーマンスや可用性の担保、デプロイの自動化などが主な業務
  • 2018/2時点でメンバーは10名
    • マイクロサービス基盤構築や機械学習プラットフォームに携わるエンジニアも
    • 大規模Webサービス運用経験のある中途が多いが、新卒メンバーも在籍
    • ここのメンバーが能動的に問題を発見し解決していく

自動化例

  • SlackでJIRAのチケットを作成
    • 寝ながらでも思いついた時に作れる

業務範囲

  • ソフトウェアエンジニアリング
    • スケーラビリティ、可用性改善、自動化、DBA、ミドルウェア構築、アプリ設計のレビュー
  • オペレーション
    • Oncall
  • 基盤構築
    • ログ収集・分析基盤、デプロイ、マイクロサービス基盤、セキュリティなど

最近の事例

  • Worker/Queueシステムの問題点
  • Jobの処理速度は様々な要因で変化する
    • バッチからのenqueue速度
    • Workerのプロセス数
    • 処理内容
  • 処理が速すぎることでシステムに負荷

内製CRMツールの事例
  • 配信の速度は配信メディアによって決まる
    • Push配信は速い、メール配信は遅いなど
  • 処理速度が一定ではない、配信ごとに変化
    • 配信にかかる時間をい自覚するためにWorkerの数を手動で調整
    • 調整漏れによって想定外の負荷・障害(DBに高負荷がかかって障害)

CruiseControl
  • 「速度を制御するサービス」を構築
  • Workerが処理を開始する前にCruiseControlに問い合わせる
    • 処理速度が速い場合はwaitが入る
  • CruiseControl = NGINX
    • nginx_http_limit_rew_modukeを利用
    • pathとheaderによって速度を制御
  • システム負荷とqueue数を見ながらWorker数を調整する職人技的対応のシステム化を実現

追記

資料が公開されています。

2018/02/15

デブサミ2018「GitHubの開発フローにおけるサポートエンジニアの役割」講演メモ #devsumi


GitHubで働いている前職の同僚がありがたいお話をしてくれるとのことで、セッションを聞きに行った。

登壇前に、手汗ぐっしょりの彼と握手をしましたが、面白い話が聞けたので、そのメモを残しておきます。


  • Hayato Matsuura
    • GitHub / Enterprise Support Engineer
    • Yakst主宰
    • 最近「入門Kubernetes」を翻訳したよ

GitHubとは

  • スローガン
    • GitHub is how people build software
  • ユーザ数: 2700万+
  • リポジトリ数: 7700万+

GitHubを支える技術

  • ベアメタルサーバで運用
    • IOバウンドなので、クラウドだとパフォーマンスが出ない
  • Rails + kubernates + MySQL + redis + Git + ...(etc.
    • ミドルウェアとしては、固めでスタンダードな選定

Gitリポジトリ冗長化システム
  • Spokes
    • 昔はDGitという名前で、DRBDで冗長化してた。これだとスケールしないので改善。
    • Spokesでは、プロキシ型のアーキテクチャをとっていて、バックエンドのストレージにデータを分散配置している

Kubernatesによるコンテナ管理
  • モノシリックな構成だが活用している
  • APIやWebなどユーザが接続するフロントのサーバで活用

GitHubでの開発の流れ

  • まず、Markdownで提案書を書いて、PRを送る
  • みんなの合意が取れたらマージして開発を進める
  • 実際の開発では、issueやprojectの機能を使い、GitHub自体で完結する開発プロセス
  • GitHub Flowを使ってスタンダードな感じで進めている

GitHubでは、デプロイしてからマージする
  • 通常だとマージしてからデプロイだけども
  • masterは常にデプロイ可能な状態
  • 動く状態を確認してからマージする
    • 一時的にでもバグの混入を防いでいる

ChatOps
  • Slack + hubotを使っている
  • いつも24時間、誰かがデプロイしている。
    • ぶつからないようにデプロイキューを作っている。
  • hubot自身が仮のブランチも作ってくれる。
  • カナリアリリースに対応済み
  • hubotがデプロイした後、運用管理システムで状態のチェック
  • 問題なさそうなら、hubotがマージを促してくれる

GitHub Enterpriseとは

  • 仮想マシンに載ったGitHub.com + 管理機能 + α
  • 仮想マシン => AWS、GCP、OpenStack、VMwareなど
  • GitHubとの差異はロゴくらいしかなく、基本的に同じ使い勝手となるようにしている

GitHub.comのお問い合わせ

  • Git/GotHubの使い方
  • 間違って消したリポジトリの復旧依頼
  • 要望、バグ報告など

GitHub Enterpriseのお問い合わせ

  • 企業のバージョン管理システムの担当者が相手
    • ユーザとそのアクションを管理する方法
    • レプリケーション設定
    • パフォーマンスの問題解決
    • 管理機能のバグ報告・機能改善要望など

GitHubのサポートの考え方

  • あえてサポートをレベルわけしていない
    • T1, 2, 3とかそういうのは無い

サポートエンジニアの働き方

GitHubの社員は世界中に分布している
  • タイムゾーンを3つにわけて、それぞれのエリアのサポートエンジニアが8時間働く
    • 世界中のお客様に対して24時間体制でサポートしている
  • 日本に限り、日本語のサポートをしている
    • ローカル言語なので、残念ながら平日9-17時でやっている

バグ報告
  • issueを作成して報告
    • 不具合の再現手順
    • 発生条件、エラーについてまとめ
  • 開発のIssueの3割は、サポートエンジニアが作成
  • しかし、場合によっては修正の必要に迫られることもある

日本に開発者がいない問題
  • そもそもAPACに開発者が少ない
  • アメリカ・ヨーロッパに多く、時差によるコミュニケーションのオーバーヘッドが発生
  • マルチバイト文字の扱いなど(不具合が残っているケース)

マルチバイト文字の扱いに関するバグの例
  • ライセンスファイルにマルチバイト文字が入るとエラー
  • 特定のGraphQLクエリにマルチバイト文字が入るとエラー
  • マルチバイト文字を含むファイル名のdiffページが特定の条件下で文字化け

サポートも開発したい気持ちもある
  • ユーザからの声を直接聞いている
  • 自分がユーザならここを直したい
  • サポートだけだと新しいことを覚えにくい
  • サポートエンジニアの主業務はサポートだが、開発も推奨
    • GHEのPRの4割近くはサポートから
    • 松浦さんも管理画面のモニタリングのグラフの生成アーキテクチャを変更するPRを投げている

サポートエンジニアはお客様のSRE
  • SRE: 自社サービス
  • サポートエンジニア: お客様のサービス
  • SREは50%以上を開発に時間をあてるべき
  • サポートエンジニアも同じように働くべき?
    • 50%と言わないまでも開発すべきだと考えている
    • ソフトウェアの中身を理解することで品質を上げる
    • ユーザの声を直接FB・反映できる
    • 開発陣の着手を待たずリリースできるかも
    • チケット量が減った際のサイドプロジェクトとして
  • サポートエンジニアも積極的に開発に関わるべき
    • 開発したいエンジニアのキャリアパスとしてもあり
      • インフラやデベロッパーの方など

お知らせ

  • 企業のお客様にもGitHubを使って欲しい
  • 日本語サポートあります
  • 日本語ドキュメントも出ます(いつかはまだ未定)
  • 日本語Webサイトを3月に公開予定
  • 2018/6 にSatellite Tokyoを開催するよ

追記

資料が公開されています。


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)