きっと、うまくいく~非IT業界をスクラムで変えるための系譜~

一人のPO見習いが業界を変えるために奔走する様子をただただ綴るブログです。

【AWS再入門】5分でわかるRDS

さて、前回から始めたAWS再入門シリーズ。 今回は業務でもAuroraの理解が再度必要になったのでAmazon RDSについてです。

ちなみにEC2はこちら

passionate-po.hatenablog.com

Amazon RDSとは

  • Amazon Relational Database Systemの略
  • 構築、運用、拡張が容易なフルマネージドのリレーショナル・データベース
  • インスタンスのStart/Stopが可能(最大7日間)

 Amazon RDS でマルチ AZ データベースインスタンスの停止および起動が可能に

対応エンジン

制限事項(Oracle Databaseの場合)

  • バージョンが限定される
  • キャパシティに上限がある
  • OSログインやファイルシステムへのアクセスはできない
  • IPアドレスは固定できないRAC,ASM,DataGuard,RMANなどは使えない
  • 個別パッチは適用できない

マルチAZデプロイメント(Multi-AZ)

  • 複数のAvailability ZoneにMasterとSlaveのインスタンスを配置
  • MasterとSlaveは同期される
  • Masterのインスタンスやハードウェアの障害があった場合、自動でSlaveがMasterに昇格(フェイルオーバー)される
  • 手動リブートによる強制フェイルオーバーも可能

リードレプリカ

インスタンスタイプ

  • EC2と同様 vCPU、メモリ、EBS最適化、ネットワークの組合せで決まる。
  • ストレージタイプは下記3タイプ
  • 汎用SSD
  • プロビジョンドIOPS
  • Magnetic
  • ストレージサイズは16TBまで(MySQL,Oracle,MariaDB,PostgreSQL)

スナップショット

  • 日時でデフォルトでスナップショットとトランザクションログが自動でS3に保存される。
  • 保存期間は最大35日分
  • 自動スナップショットはインスタンス削除時に削除される
  • 上記とは別に手動でスナップショットは任意で取得可能。削除も自由
  • スナップショットを元にインスタンスを立ち上げることが可能(リストア)
  • リージョン間、アカウント間でコピー可能
  • スナップショット実行時にI/Oが一時停止する(マルチAZの時は気にしなくてOK)

メンテナンスウインドウ

  • 数ヶ月に一度発生するメンテナンスのタイミングを何曜日の何時に実行して欲しいのかユーザーが指定する
  • 指定した時間帯の中で数分間実行される(詳細な時間は内容による)

暗号化

  • DBインスタンス、自動バックアップ、リードレプリカ、スナップショットを暗号化可能
  • データアクセスと復号の認証は透過的に処理するので気にしなくて良い
  • AWS KMSで鍵管理が可能
  • 対応しているインスタンスタイプは限定される
  • インスタンス作成時のみ設定可能

Amazon Aurora

  • Amazonクラウド時代向けに再設計したDB
  • MySQL5.6、5.7互換
  • MySQLのエコシステムをそのまま活用可能
  • 多くの3rd Party監視ツールを利用可能
  • 3つのAZの6つのディスクに書き込まれる  - 2つのディスクに障害が起きてもread/writeが可能  - 3つのディスク障害が起きてもreadが可能
  • キャッシュとログがプロセスから分離されているので、再起動をしてもキャッシュが残る
  • AES-256で暗号化
  • KMSを利用したキー管理が可能
  • SSDを利用したシームレスにスケールするストレージ
  • リードレプリカもマスタと同じストレージを参照
  • 増分を継続的にS3にバックアップ
  • 64TBまでシームレスに拡張するストレージ
  • 自動で際ストライピング、ミラー修復、ホットスポット管理、暗号化
  • リードレプリカが存在する場合、1分程度でフェイルオーバー
  • クラスタ(WriterとReaderのセット)で常にWriterを示すEndpointが存在する
  • 各ノードそれぞれにEndpointを持っている
  • そのため、フェイルオーバ発生時はノードの昇格が行われ、クラスタEndpointのさし先が変わる
  • Adaptive Thread Pool:アクティブなスレッドに複数コネクションがはられている。スレッド数は動的に変わる
  • MySQLのSnapshotから作成可能

料金モデル

Aurora以外

  • DBインスタンス($/時間)  - 1時間単位で利用可能  - ライセンス込み or BYOL  - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
  • ストレージ($/GB/月)  - ストレージ容量、I/Oリクエスト数  - バックアップストレージ容量($/GB/月)
  • データ転送  - 別のリージョンへのデータ通信($/GB)  - インターネットへのデータ通信($/GB)

Aurora

  • DBインスタンス($/時間)  - 1時間単位で利用可能  - MySQL互換 or PostgreSQL互換  - DBエンジン、インスタンスタイプ、 Multi-AZなどで料金が変わる
  • ストレージ($/GB/月)  - ストレージ容量、I/Oリクエスト数  - バックアップストレージ容量($/GB/月)
  • データ転送  - 別のリージョンへのデータ通信($/GB)  - インターネットへのデータ通信($/GB)

2つの価格モデル

まとめと私の思うポイント(あくまでテスト対策)

  • パフォーマンスを考えるとAuroraを採用するのが解
  • ただ、考え方の根本が異なるので、理解を深めてチューニングしないとパフォーマンスがイマイチなことも
  • デフォルトのパラメータグループで最適サイズのインスタンスを選ぶことから始める。
  • うまくいかなかったらパラメータグループをいじってみるのが良いかも
  • クエリの同時実行数やテーブルサイズが大きい時に有効と言われているが、そこまでこだわらず、基本的にAuroraで良い気もしている
  • 複数のサーバにシャーディングしている場合、1つのAuroraにまとめると良さそう(内部的には一つではないので)
  • 現在がMySQLで動いてたら、そのスナップショットから作成してみるとはじめやすいかも。

【コラム】本業がフルフルの中で時間を作るための工夫

今回は

The Agile Guild(TAG) Advent Calendar 2018 7日目の記事として書いてみました。

qiita.com

突然ですが、みなさん忙しいですか?

そりゃそうですよね。 私も週5で8時間 + 残業 で勤務をしているのでとてもわかります。

ただ、そんな中でも本業以外のコミュニティー活動、複業、趣味の時間をつくるために私がやっていることをつらつらと書いていこうかと思います。

なぜ、自分の時間を使ってまで活動をするのか

私は主に本業の他に The Agile Guildに7月に、DevLOVEというコミュニティーに3月に参加させていただいています。

そもそも、それまでの私は毎日9:30に出勤し、タスクに追われて22時まで時にはテッペンまで働くことも厭わないようなスタイルでした。 ただ、2018年2月のDevSumiでのある講演を聞いてから私の生活は一変しました。

ちなみにそれについてまとめた記事がこちら。

passionate-po.hatenablog.com

このブログを始めるきっかけにもなりました。

どんな衝撃を受けたかというと・・・

  • 毎日悶々としている中で背中を押してくれた
  • 今の自分の状況を打開するヒントがあった

という点です。ここでいくつか気づきを得ました。 それは

  • 社内では初めてのことをやっていても外の世界にはすごい人がいっぱいいる!
  • 自分にできることは社外にもあるのではないか?
  • 同じ志を持った同志は社外にもいるかもしれない。

そこから、カクカクシカジカありまして・・・DevLOVEにJoinしました。  ※ ここにまとめてます。

www.slideshare.net

ここで思ったのが、

やってみよう!と思うのは誰でもできる。しかし、やらない理由 > やる理由になる人がほとんどではないか?

という疑問です。 例えば、本業以外にやりたいことがあっても、やらない理由はたくさん思いつきます。

  • 疲れるし・・・
  • 遊びたいし・・・
  • 家族がいるし・・・
  • 嫁がいるし・・・
  • 子供がいるし・・・
  • 会社がダメって言うし・・・
  • 自分レベルがわからないし・・・
  • 本業忙しいし・・・
  • 時間ないし・・・

などなど。ただ、そこで諦めていたら、次のステージに進む速度は本業で得られる成長スピードでしかないかなと私は思いました。 そして、本業では得られないスキルを社外の人は持っているかもしれないと。

私にとってそれは「仮説検証」というものでした。

私とTAGと

私は本業でエンジニアとして働いています。 主な業務は、PM、PO、スクラムマスター、AWSエンジニア、セールスエンジニアといった感じで1000人規模の企業においてエンジニア10人弱のチームで37のプロダクトを作っています。 そのため、プロダクトマネージメントという観点で当然ながら顧客に対するマーケティングも行います。 しかし、私の所属する企業では、「マーケティング = 営業の仕事。PMは開発のみに携わる」という文化が根付いていました。 そのため、いくら外部の方とお話ししたり本を読んだりして得た知識で説得を試みてもどことない「顧客のことは営業の方が分かっている」という空気に押し出されて、正しいことができない状況にありました。

しかし、案の定、マーケティングはうまくいかず、手塩をかけて育てたプロダクトは何回も沈んでいきました。 私はもうそんな思いはしたくない。しかし、自分の力不足は否めない。

そこで、直談判し、TAGにおける仮説検証業務にくわえさせてもらいました。

そのため、私におけるTAGの活動は

  • 複業で小遣いを稼ぐ
  • 自分の実力を確かめる

でもなく、

  • 自分が成長する
  • TAGにも貢献したい
  • それを本業や業界にも還元する
  • そして、自分にしかできない形で社会に貢献したい

という側面が強いです。

複業との向き合い方

と私の複業との向き合い方を書いてきましたが、 複業をどう考えるかは人それぞれだと思います。

  • 空いた時間でお金を稼ぎたい
  • 自分のスキルを活かしたい
  • 自分のスキルを伸ばしたい
  • 人脈を作りたい
  • 世の中を良くしたい

どれもありだと思います。 間違っていないと思います。

では、そのために使う時間は本当に残されていないのでしょうか?

時間を作る工夫

では、具体的に私が時間を作る些細な工夫についてです。

  • 行きの電車:調べ物や読書に使う
  • 業務中の移動時間:メールやSlackのどうでも言い返しは全てこの時間でしか行わない
  • 業務後:積極的に打合せや勉強会を入れて体を慣れさせtる
  • 帰りの電車:1日の振り返りと帰宅後のアジェンダを脳内で組み立て
  • 帰宅後:入浴後に必ず1時間は確保。ここでブログを書いたり、仕事をしたり。
  • 入浴中:アイディア出しの時間に使う
  • 就寝直前:読書で頭を休ませ、眠気を誘う

正直全て大したことがないです。ただ、こんな大したことがない方法で時間は作れます。気持ちさえあれば!

改めて・・・

そのために使う時間は本当に残されていないのでしょうか? やらない理由 > やる理由 になってませんか?

もし、一歩踏み出そうと思った方は、こちらから門を叩いてみてください。

theagileguild.org

【読書感想】スクラム現場ガイド ~スクラムを始めてみたけどうまくいかない時に読む本~

今日はXP祭りの登壇時にいただいたこの本。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

ちょうど私自身がステークホルダーとしてスクラムでプロジェクトがひと段落し、来月からProduct Ornerとしてのプロジェクトを始めるうえで、読んでとても良かったと実感しました。

この本の読んで良かった点や感じた3つのことをまとめていきます。

各ポイントを網羅した各テーマ

 この書籍は30章の章立てがされています。それぞれは10~15ページで構成されていて、サクサクと読めるもの内容です。 そしてこの各章も準備から実践、緊急対応、上級者向けとステップをおいて書かれており、基礎から応用まで順を追って学ぶことができます。  特に終盤は受託企業としての契約方法プロジェクトコストの見積もりなど他のスクラム導入書ではなかなか得られないアドバイスが含まれています。

イメージしやすいストーリーと解説

 というわけで、各章、満遍なく押さえてられています。一方で、章の中の構成もストレートでわかりやすい構成になっています。 まずは想像しやすいようなストーリー形式でシチュエーションを想像させ、そのストーリーの解説を挟み、最後には実践した際の実践の鍵という構成です。 この構成のおかげでストーリーを読みながら、実践をイメージし、自分の場合の難易度やどう実践しようかを考えている間に解説でストーリーでわかりにくいところをさらに紐解き、難しいと感じている部分のヒントを左もらえる構成で、実践がうずうずなるような印象です。

自分が実践し、成功するための鍵

 先述の通り、各賞の最後には"成功の鍵"というページがあり、ここで実践に向けたアドバイスが書かれています。 ただ、この書籍自体が訳書ということで、アメリカ文化と日本文化のギャップは多少感じますが、実際の自分ごと感をしっかり与えてくれるだけでなく、自分への問いを自然に生まれるものでした。

今後のこの書籍との向き合い方

 この書籍はある意味、百科事典のような付き合い方もできるかなと感じました。 実際に自分が壁にぶつかった時に逆引きして課題を乗り越えたり、向き合うことに使えると思いました。

そのため、会社のデスクの脇にいつでも手に取れるようにおいておきたい一冊です。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

【AWS再入門】5分でわかるEC2

AWS Solution Architectをとってもうすぐ早2年。 更新をするにあたり、最新情報をおさらいしようと思います。なので、それに合わせて自分の"学び直したこと"と"気になったこと"をこのブログにも書いていこうかと思います。今日は最初にして最大の情報量になるだろうAmazon EC2です。

Amazon EC2とは

リージョンとは?

  • いわゆる国、エリアの概念
  • 複数データセンターの集合体
  • 2018年現在 18のリージョンと1つのローカルリージョンが存在
  • ローカルリージョンとは機能や性能が制限されているリージョン(ちなみに大阪)
  • ローカルリージョンを除くリージョンは2つ以上のアベイラビリティーゾーンで構成されている
  • リージョン間は高速ネットワークが構築されている

アベイラビリティーゾーン(AZ)

  • リージョン内に複数存在する
  • 地理、電源、ネットワーク、空調などを互いに影響を受けないレベルで別れたデータセンターの単位 (よくデータセンターそのものと表現する人もいるが厳密には複数あるらしいのでデータセンター"群")
  • リージョン内での災害対策の地理冗長などを目的に複数AZにインスタンスを立ててを組み合わせて利用することが多い

EC2の物理基盤

EC2インスタンスの種類

  • インスタンスファミリー + 世代 . インスタンスサイズ という記法で表現 ex) c5.large
  • インスタンスファミリー:何に最適かしているか
  • 世代:文字通り世代。
  • インスタンスサイズ:バーチャルCPU、メモリ、RAM、ネットワークスペックの大小
  • インスタンスファミリーと現行の世代は以下  - T2:汎用(開発環境など向け)  - M5:汎用(小中規模のDBなど)  - C5:コンピュート最適化  - D2:ストレージ最適化(Big Dataなど)  - H1:ストレージ最適化(同じくBig Dataなど)  - I3:ストレージ最適化(NoSQL DWHなど)  - R4;メモリ最適化(ハイパフォーマンスDB)  - X1e:メモリ最適化(インメモリDB)  - G3:アクセラレーテッド(3Dレンダリング)  - P3:アクセラレーテッド(機械学習)  - F1:アクセラレーテッド(ゲノム解析)
  • 通常は低負荷だが稀にスパイクするサービスのためにT2 unlimitedというオプション機能がある

物理ホストの占有

  • ハードウェア占有インスタンス/ EC2 Dedigated Hostの2択
  • どちらも専用の物理サーバでインスタンスを起動
  • EC2 Dedicated Hostはハードウェア単位のBYOL(ライセンス持ち込み)が可能
  • ただしハードウェア自体の直アクセスは両方できない
  • そこで第3の選択肢AWS EC" BareMetal」がプレビュー中
  • ハードウェアへのダイレクトアクセスを提供する新しいEC2インスタンスのシリーズ

EC2の機能

  • Key pair:EC2は公開鍵認証でアクセスをする。そのための公開鍵と秘密鍵の組み合わせ
  • Security Group:インスタンス単位のFirewall機能
  • Elastic IP:インスタンスにアタッチできる固定のパブリックIPアドレス
  • Elastic Network Interfaces (ENI):EC2をホストするVPC(Virtual Private Cloud)内の仮想ネットワークインタフェース
  • 拡張ネットワーキング:各インスタンスの通信性能を最適化する機能
  • Cluster Placement Groups:各インスタンスをグループ化してインスタンス間のネットワーク通信を最適化する機能
  • Auto recovery:何らかの原因でインスタンスが落ちた場合に自動復旧させるオプション(起動時の実行コマンドも仕込める)

EC2のストレージ

Amazon Machine Image

インスタンスのライフサイクル

  • 起動/停止/削除の3パターン
  • 起動(Start):文字通り実行。Stoped→Runningにステータスが変わる
  • 停止 (Stop):停止状態。Running→Stopedにステータスが変わる
  • 削除(Terminate):削除状態。インスタンス自体を破棄しているので、二度と同じインスタンスは立てられなくなる。

EC2の費用

  • 起動時間の1秒単位で課金
  • インスタンスの種類によって単価が分かる
  • 購入オプションごとにも金額が変わる

購入オプション

  • 以下の5種類
  • オンデマンドインスタンス:初期費用無し、従量課金
  • リザーブインスタンス:1年間または3年間、常に利用可能なキャパシティ予約により、最大75%の割引
  • スポットインスタンス:未使用キャパシティを時価で提供、最大90%の大幅な割引で利用可能。ベットした金額を上回る入札があれば強制終了される
  • 専用ホスト(Dedicated Hosts):インスタンス実行用物理ホストの単位で支払い。
  • ハードウェア専有インスタンス( Dedicated Instance):シングルテナントのため丸々かかる

まとめと私の思うポイント(あくまでテスト対策)

  • インスタンスストアボリュームとEBSの違いは実運用においても重要かつテストでも出題されや類のでしっかりと理解する必要がある
  • 課金単位はしばらく前は分単位だったので秒単位になっていることを理解するのが大事
  • リージョンとアベイラビリティーゾーンの関係、そして必要性はとても重要。EC2以外にも関わるので押さえておくこと
  • インスタンスタイプはざっくりとそれぞれどこを最適かしているのかだけ抑えることが重要
  • ここで押さえているのはあくまで概要なのでそれぞれの機能でもたらされるメリットや注意点はしっかり調べることが大事

【コラム】RSGT2019で話したかったこと!

来たる2019年1月、毎年恒例となりました、Regional Scrum Gathering Tokyo2019が開催されます。

このイベントのセッションは10月に公募がなされていて、計80を超える応募の中から約30のセッションが行われます。 私も下記の2つを応募してみました!

confengine.com

confengine.com

残念ながら、両方とも採択されるに至らなかったのですが、今回はこの講演でどんな話をしたかったのか、整理してみようと思います。

序文に抱いた思い

今回はまず序文にこんなことを書きました。

"チームで仕事をする"という場面において、気心の知れた仲間や同じ価値観を持った仲間のみとチームを組成できる機会はそうそうありません。

むしろ、自分と異なるスキルや価値観を持つ人や初対面でのチーム組成も少なくありません。

そして、プロダクトを生み出すにあたり、エンジニアのみではなく、企画職、営業職など文化の異なるメンバーが集まることも当然必要になります。

一方で、「スクラム」「アジャイル」といった流儀を営業や企画職にうまく伝え、一緒に進めていくのも一苦労。

言葉の違うチームにおいて、お互いを知りながら、チームを形成するために私が行った「営業、エンジニア合同のスクラム勉強会」についてワークショップ設計時の工夫、そこでの学びをお話しします。

また、初めてでも同じように組織にチームビルディングのワークショップを行っていただけるようなポイントについても紐解いていきます。

これは私が携わっているプロジェクトでのモヤモヤから生まれたものです。 私の所属する会社はソフトウェア、ハードウェア、ネットワークエンジニアが全体の約1%です。 そのため、プロダクトに関しても複数を同時にこなし、チームも2,3人がメッシュ状に絡まなくてはならない、スクラムでいうとアンチパターンに相当する状態で、ビジネスの規模や需要を考えるとここは仕方ない状態です。

 一方でチームとしては気心の知れたメンバーとのやりとりを基本としてはいますが、チームビルディングやカイゼン、ふりかえりを重んじる空気には育ちました。  開発チームとしてはそんな状態ではありますが、複数あるプロジェクトにおいては各部署や外部の顧客などステークホルダー異なり、また複数存在するパターンが多くあります。  そのため、PdMに相当する人間が調整を進めていきます。 ただし、発話する言葉の種類や観ている世界が異なることですれ違いやお見合い状態が多く発生しています。  特にそれはメンバーと外部の顧客というよりも

 開発チーム - 担当営業 - 外部顧客

という構図の中で

 開発チーム - 担当営業

によく起こります。中には 開発チームと外部顧客は意思疎通ができているのに、担当営業との方向が揃わないこともあります。 具体的には

 外部顧客「(優先順位は高くないから)もし可能であればお願いしたい」  開発チーム「根本の設計思想に影響するので、代替案としてこれはどうか?」  外部顧客「OK!」

 担当営業「いやいや、顧客が最もやりたかったのはそれじゃないから、叶えないと!

といったことが起こります。

これはどうして起こるのか?私はいろいろ調べてみました。

あらゆるアジャイルスクラムの書籍や勉強会に参加してもなかなか見つからない。

一つ見えてきたのはそれぞれの役割で

  • 評価者が違う
  • ゴールが違う
  • 価値観が違う
  • 嬉しいポイントが違う

と言った点が大きいということ。ただし、これは当たり前ではありつつも解決策に直接結びつくものではありません。 そんな中で出会ったのが、Jeff Patton氏のCSPO(スクラムアライアンス認定プロダクトオーナー)研修で出会った "ディスカバリーチーム"という考えでした。

ディスカバリーチームという考え方

ディスカバリーチームとは開発チームのみならず、営業、企画、アナリスト、デザイナーなども含めたチームでプロダクトを開発する前にインタビューやプロトタイプを活用した仮説検証を行うことで「本当に必要なものだけを作ることに専念する」という考え方です。

 この考え方に感銘を受けた私はそこからいろいろと仮説検証を学ばせていただいています。

では、ディスカバリーチームを組めばそれでいいのか?

私はそうではないと思います。

というのも、開発チームで新しいプロジェクトにのぞむ時に

  • インセプションデッキやゴールデンサークルをつくり・・・
  • ドラッガー風エクササイズでチームの期待値をすり合わせ・・・
  • 仮説キャンバスなどでプロジェクトのあらましを理解し・・・

という行動は開発チームはおろかプロジェクトに関わる全員が行うべきではないでしょうか?

そう、それはアジャイルスクラムを知っていようがいなかろうが

"アジャイル"、"スクラム"は開発チームだけのものではない。

ただ、いきなりそんなことを言って「なんだそりゃ?」となるのも当然です。 なので、私は営業と企画を交えたスクラム勉強会を開催しました。

内容は全6回で座学半分、ワークショップ半分というで

  • アジャイルって何?スクラムって何?
  • POとは?SMとは?チームとは?
  • 相対見積もりとは?ベロシティーとは?
  • 各種セレモニーの意味と内容とは?
  • 心理的安全性の高いチームとは?
  • プロジェクト、プロダクトのゴールとは?

と言った話をしました。

そんな私の取り組みの中からの気づきや「まだ始められてないけど、どうしたらいいのか?」と言った方々に伝えられればと思って申し込んでみたのが今回の内容でした。

今回は残念ながら採択されませんでしたが、もしご興味がある方がいれば、DevLOVEなど他の場で是非お話しさせていただければと思います。

あらためてS3のデータ整合性モデルを整理してみる(2018年11月現在)

いつも"アジャイル"とか"スクラム"、"カイゼン"みたいな文脈で書いているのですが、 普段の業務の中での関わりが大きいAWSについても書いていこうかと思います。

とある出来事

私の勤める会社のSlackには「困りごとch」というものを設けています。 先日、そこにこんな投稿がありました。

ruby aws-sdkで困りごと s3にオブジェクト登録→ラムダ発火でapi叩く→そのs3オブジェクトにアクセス(deniedされる)→1秒sleep→同じs3オブジェクトにアクセス(成功) なぜすでにあるオブジェクトにアクセスしているのにdeniedされてしまうのか、 一秒待つとdeniedされないのか、わからなくて困っています。

「ああ、あれじゃん!」 と思う方、その通りです。

AWS S3 のデータ整合性モデルに絡んだ話です。

公式のデータ整合性モデル

AWS自体が日進月歩の世界なので、この記事もすぐに廃れてしまうわけですが、 現状を整理しておきます。

ポイント1:もうリージョンごとの差異はない

2015年時点ではこのデータ整合性モデルは

  1. US Standardリージョン
  2. それ以外

で一部の挙動が異なっていました。

しかし、2018年11月現在ではこれが解消され、全てのリージョンで統一されています。

 ※2015年8月にアップデートされました。

ポイント2:オペレーション内容によって異なる

データ整合性モデルはどんなオペレーションを行うかによっても異なります。 具体的には

  1. 新規登録(New PUTs) = 書き込み後の読み込み整合性
  2. 更新(Overwrite PUTs) = 結果整合性
  3. 削除(DELETE) = 結果整合性

という3パターンがあります。

ポイント3:「書き込み後の読み込み整合性」と「結果整合性」の違い

ここで、独自の言葉が2つ出てきました。 この二つの意味はというと

  • 書き込み後の読み取り結果整合性 = 登録後すぐにオブジェクトを参照できる(書き込んだ後の読み取りがすぐにできる)
  • 結果整合性 = 動作後に読み込みをしても動作前の状態が参照される場合がある(その時点での結果次第)

つまり、ここまでを整理すると

「新規登録したオブジェクトはすぐ参照できるが、それ以外は即時には反映されないこともあるよ」

ということです。

とはいえ、実際は違う!

ここまではあくまで公式で発表されている内容です。Solution Architectの試験などの範囲でもあります。 ただ、これだけを信じていると実際の現場ではハマります!!

そうこれが困りごとchに流れてきた事象です。

端的にお話しすると

「書き込み後の読み込み整合性」とはいっても、書き込みが終わらなきゃ読み込みはできない

ということです。 オブジェクトの新規作成についてはオブジェクトのサイズや種類によらず、書き込み後の読み込み整合性を宣言しています。

しかし、実際はS3に格納後、アクセスできるようになるためにはS3内部で何かしらの処理が行われているので、 稀にアクセスできないことがあります。

これは、いろんなところでも言われています。

こちらの記事より

新しいオブジェクトを Amazon S3 に書き込み、すぐに読み取りを試みます。変更が完全に反映されるまで、Amazon S3は「キーが存在しません」というレポートを表示する場合があります。 新しいオブジェクトを Amazon S3 に書き込み、すぐにバケット内のキーのリストを表示します。変更が完全に反映されるまで、オブジェクトがリストに表示されないことがあります。

そして公式にも

Amazon S3 では、すべてのリージョンで S3 バケットの新しいオブジェクトの PUTS については "書き込み後の読み込み" 整合性を提供しますが、注意点があります。注意点は、オブジェクトを作成する前に (オブジェクトが存在するかどうかを調べるために) キー名への HEAD または GET リクエストを実行する場合、Amazon S3 は、読み込み後の書き込みに対して結果整合性を提供する、という事です。

ドキュメントだけじゃなく、触ってみよう

ということで、ドキュメントで理解できること以外に実際に触ってみると「あれ?」と思うことや「おや?」と思うことがあります。 なので、一番は自分で触ってみること。そして悩んだら、サポートに問い合わせたり、聞いてみること。

そうすることで、知見が広がり、世の中のみんながハッピーになります。

というわけで、誰かの参考になればと思います。

【ワークショップ開催】第4回こそ勉Lab.「あの映像どうなってるの?~気になる映像技術~」

さてさて、今日はうちの会社らしい社内勉強会を開催しました!

今日は先輩社員によるドメイン知識バリバリの内容。 テーマに沿ってこのようなものの最新事例を関わったものや世の中の動向を元にお話いただきました。

  • AR
  • VR
  • OOH

などなど。

f:id:HirokiHachisuka:20181103162915j:plain

90分という尺の中で

「どれが実写でどれがCG?」というクイズであったり、

f:id:HirokiHachisuka:20181103162247j:plain

Youtubeの動画を再生しながらの解説など、とてもためになる内容でした!

そして最後にはワークショップ! 「学んだことを踏まえて、どうやって新しい技術を生むか」という視点で3チームに分かれて進めました!

f:id:HirokiHachisuka:20181103165106j:plain

f:id:HirokiHachisuka:20181103172217j:plain

また、今回は参加者も10月に合併するまでは別会社だった方や初参加の方もいて、 次に繋がるいい会になりました!

ここ2回で「私以外の方が会をやる!」という目標は達成し、話してもらう土壌が整ったので、 次はまた、私がお話しさせてもらおうかなと思ってます。

そして次の野望としては

  • 平日、休日で参加者の層が違うので、それに合わせて実施
  • 別拠点のリモート参加
  • 裾野を広げる為のメルマガ
  • グループ会社への拡散

とどんどんと仲間を巻き込んで加速していこうと思います!