pythonで通年の時系列データを各年度ごとのグラフにするときに便利なテクニック
for 文と groupby()でDataFrameから、指定したキーワード1カラムと、残りのDataFrameを交互に抽出することで、
タイトルどおり、pythonで通年の時系列データを各年度ごとのグラフにするときに便利なテクニックを学びましたのでまとめます。
参考 kaggle の M5コンペ U.takahiro さんのNotebook より
前提
使う元々の表
import pandas as pd df = pd.DataFrame( { "year":[2015, 2016, 2017,2018,2019,2020], 1:[100, 200, 300, 400,500,600], 2:[500,600,700,800,900,1000], 3:[300,900,1200,1500,1800,2100], 4:[400,800,1200,1600,2000,2400], 5:[50,100,150,200,250,300], 6:[150,300,450,600,750,900], 7:[80,160,240,320,400,480], 8:[1,4,9,16,25,36], 9:[33,66,99,132,198,231], 10:[20,40,80,160,320,640], 11:[5,10,15,20,25,30], 12:[25,50,75,100,125,150] } )
加工前の表です。
そしてこれを一旦グラフ化しやすい表に修正します。
詳しくは前のブログで触れています。
# for文とiloc を駆使して、1か月ごとに表を組み替え df2 = pd.DataFrame() for i in range(1,13): df3 = df.iloc[0 : ,[0 , i ]] df3["month"] = i df3 = df3.rename(columns={i:"mount"}) df2 = pd.concat([df2, df3]) df2["times"] = df2["year"].astype(str) + "/" + df2["month"].astype(str) +"/1" df2["times"] = pd.to_datetime(df2["times"], format="%Y/%m/%d") df2 = df2.sort_values("times") plt.plot(df2["times"], df2["mount"]) df2 = df2.loc[:,["times","year", "month", "mount"]] df2 = df2.reset_index().drop("index", axis=1)
これで前提となる表が出来ました。
グラフ化すると、通年のグラフが表示されます。
ここからが本題ですが、これを各年度ごとのグラフにしてみましょう。
# year に groupby()で指定した df2["year"]の要素が、 df_tmpに df2のdf2["year"]以外の要素が入ります。 # df2のdf2["year"]以外の要素をグラフ化し、x軸にdf2["times"]、y軸にdf2["mount"]を指定します。 for year, df_tmp in df2.groupby('year'): df_tmp.plot(x='times', y='mount', figsize=(15, 5))
これで各年ごとのグラフを作成することができます。
for 文の year をタイトルに指定することで、各グラフのタイトルに年度を入れることもできます。
以上になります、最後までお読みいただきありがとうございました。
pythonのpandasで表を並び替えるテクニック
次のような各年度の各月の数字が並んでいる表があった場合、グラフ化しようとすると一筋縄ではいきませんよね。
参考）写真の表は下記をコピペすれば作成できます。
import pandas as pd df = pd.DataFrame( { "year":[2015, 2016, 2017,2018,2019,2020], 1:[100, 200, 300, 400,500,600], 2:[500,600,700,800,900,1000], 3:[300,900,1200,1500,1800,2100], 4:[400,800,1200,1600,2000,2400], 5:[50,100,150,200,250,300], 6:[150,300,450,600,750,900], 7:[80,160,240,320,400,480], 8:[1,4,9,16,25,36], 9:[33,66,99,132,198,231], 10:[20,40,80,160,320,640], 11:[5,10,15,20,25,30], 12:[25,50,75,100,125,150] } )
Excelならピポットテーブルを組んで、フィールドリストのΣ値を入れ替えることで下記の写真のような表が作成できるのですが、pythonではどのようにすればいいのか、つまづいたのでまとめてみました。
結論から言いますと、for 文と iloc を駆使することで、上記のような表に作り替えることができます。
さっそくコードを見てみましょう。
なお、今回のコードは以下のサイトを参考にさせていただきました。
# ライブラリのインポート import pandas as pd import os import matplotlib.pyplot as plt # for文とiloc を駆使して組み替えた表を結合・集約するためのからっぽのDataFrameを作成。 df2 = pd.DataFrame() # for文とiloc を駆使して、1か月ごとに表を組み替え # 1月～12月の12回繰り返しのfor文 for i in range(1,13): # インデックス（行）はilocの左半分の [0: , ... で全て抽出し、カラム（列）は右半分の [0 , i] で year カラムと、1番目～12番目にある各月のカラムを抽出 df3 = df.iloc[0 : ,[0 , i ]] # 新しく月の数字を入れる month カラムを作成 df3["month"] = i # 結合するにあたり、カラム名が 数字（例：1月は 1）のままだと結合がうまくいかないので、共通のカラム名（mount）に変更 df3 = df3.rename(columns={i:"mount"}) # カラの表と、集計した1ヶ月分の表を結合。これを12か月分繰り返す。 df2 = pd.concat([df2, df3])
カラムの並びや index の番号がぐちゃぐちゃなのが気になりますが、グラフ化しやすい表が出来上がります。
グラフ化のために日付データのカラムを追加してあげましょう。
# 要素を文字列に変換した year カラムと 同じく文字列に変換した month カラム、適当に日は1にした times カラムを追加します。 df2["times"] = df2["year"].astype(str) + "/" + df2["month"].astype(str) +"/1" # 文字データのままソートするとぐちゃぐちゃになるので、日付データに変換します。 df2["times"] = pd.to_datetime(df2["times"], format="%Y/%m/%d") # times 列でソートします df2 = df2.sort_values("times")
これできれいにグラフが作成できます！
plt.plot(df2["times"], df2["mount"])
さて、これで終わりでもよいのですが、せっかくなのでカラムを並び替えたり、インデックスをきれいにするテクニックもご紹介しましょう。
# loc[: ,[カラム名] で任意の列の並びで抽出しなおすことができます。 df2 = df2.loc[:,["times","year", "month", "mount"]] # index の順番を reset_index()で振りなおすことができます。 # ただし、reset_index() を使うと、index という余計なカラムが新たに作成されてしまいますので、これをdrop()で削除します。 df2 = df2.reset_index().drop("index", axis=1) df2.head(100)
これでカラムも並び替えることができました！
以上になります、最後までお読みいただきありがとうございました。
参考サイト
うちでやりたいこと
mottox2さんの、うちでやりたい〇つのこと、という記事をよみ、外出自粛とリモートワークで悶々とする中でも、自宅でこういうことやりたい！と前向きに考えるの大事だなと思いました。
さっそくパクり参考にさせていただきました！
欲しいもの
- PS4買ってFF7リメイクやりたい。
- ホットクック欲しい。
- Steamのゲームやってみたい。
- アイスクリームメーカー買って自家製アイス食べたい。
食べたいもの
- ホットサンドメーカー買ったので、レシピ見てホットサンド作る。
- 一日外出録ハンチョウの深夜の凶悪飯の再現
趣味
開発
- GCPで簡単なデータ分析・機械学習ツールを作る。
- 確率思考の戦略論をpythonで組んでみる。
- pythonで自作のゲーム作る。
その他
- CBTで統計検定2級合格。
以上になります、最後までお読みいただきありがとうございました。
ABL 「ジッターを伴うタイムアウト、再試行、およびバックオフ」を読んだ
（追記）輪読会資料を追加。
輪読会の発表に向けて、Amazon Builder's Library（以下、ABL） を読んだので、簡単にまとめてみました。
テーマは「ジッターを伴うタイムアウト、再試行、およびバックオフ」です。
ざっくり理解のためのメモ
・サーバーへのアクセスが失敗したとき、いかに負荷を上げすぎず再アクセスをするか、のAmazonがとってる仕組みが学べる。
・ジッター サーバーへのアクセスを散らすために、各システムからのアクセスをずらす仕組み。本来の意味はは『タイミングのゆらぎ』。
・再試行 システムの応答がない時に、もう一回リクエストかけること。 解決することも多いが、下手すると再試行が失敗し続け負荷を上げてしまいサーバーが落ちるかも。
・バックオフ 間隔をあけること
（参考）輪読会資料
なお記事のほうは、Amazon Web Service のシニアプリンシパルエンジニアの方が書いておりまして、項目は、以下の5つでした。
はじめに 障害の発生
タイムアウト
再試行とバックオフ
ジッター
まとめ
それでは内容について触れていきたいと思います。
はじめに 障害の発生
障害の発生要因は様々
サーバー、ネットワーク、ロードバランサー、ソフトウェア、オペレーティングシステム、システムのオペレーターの操作ミス 等
故障しないシステムは構築不可能
Amazonでは、障害の発生は許容しつつ、障害によりサーバーが停止しない仕組みとして以下の3つを採用している。
① タイムアウト
リクエストが長期化すると、リソース切れになる恐れがあるので、クライアントはタイムアウトを設定する。
② 再試行
多くの場合は再試行は成功する。
リクエストの一部失敗や、短期間の失敗に耐えることが可能。
すべてのクライアントが同時に再試行すると、再試行が無駄になる可能性がある。
この問題を回避するために、ジッター（タイミングを意図的にずらす仕組み）を使用する。
ジッタ（jitter）とは、デジタル信号の「タイミングの揺らぎ」のことです。
③ バックオフ
再試行はリソースが少ないときに、負荷を増加させてしまうため、バックオフ（再試行の間隔を長くすること）を実装する。
べき等（同一のパラメーターで 1 回以上リクエストしても、リソースの状態が同じであること）がベストプラクティス。
参考
HTTP リクエストメソッドにおける「冪等」とは、「同一のパラメーターで 1 回以上リクエストしても、リソースの状態が同じであること」をいいます。
HTTP において「冪等」を定義する目的は、もしクライアントがサーバーからのリクエスト成功の応答を受信する前に通信障害が発生した場合、クライアントはリクエストをリトライしてそのリクエストの目的を達成する必要があり、サーバーはそのリトライによるリソースの不整合から保護しなければなりません。
さらに、クライアントは、同じリクエストをリトライするとリソースの整合性が破壊されるとなれば、リトライはできなくなるでしょうし、そのリトライによりリソースの整合性が保護されるのか、破壊されるのかを知らなければ無闇にリトライもできなくなるでしょう。
したがって、サーバーはこのような堅牢性を確保するとともに、クライアントにリトライ可否の区別を知らせなければなりません。
これが本来の「冪等」の目的であり、「リソースの状態の変化」に着目する理由はここにあります。
負荷が増加してエラーが発生した場合に、同時に再試行が発生するとさらに負荷が上がる。
タイムアウト
リモートの呼び出しにタイムアウトを設定するのがAmazonのベストプラクティス。
タイムアウトの設定値を決めるのが最も難しい問題
値が大きすぎると、タイムアウトされるまでの間消費されるリソースが増加する
値が小さすぎると、
再試行のリクエスト数が増加して、トラフィック量が増加して遅延が増加
リクエストの再試行のタイミングが被って、小さなバックエンドの遅延が増加し、サーバーが停止する
AWS リージョンにおいて、タイムアウトの基準は、下流のサービスの遅延状況を指標にするのがベストプラクティス。
なので、Amazon では、とあるサービスに別のサービスを呼び出しさせるとき、許容されるタイムアウトの相違の割合 (たとえば0.1%) を選択する。
次に、対応する下流のサービス遅延のパーセンタイルを調べる (さきほどのパターンだと99.9パーセンタイル)。
→おそらくリクエストの99.9%は再試行してうまく行った場合含めうまく行き、0.1%は遅延してタイムアウトすることを許容、という意味？
（参考）グーグル翻訳 stackoverflow.com
P99レイテンシは何を表していますか？私はこれについてアプリケーションのパフォーマンスに関する議論で耳にし続けていますが、これについて話すリソースをオンラインで見つけることができませんでした。
それはだ99パーセンタイル。つまり、リクエストの99％は、指定されたレイテンシよりも高速である必要があります。言い換えると、リクエストの1％だけが遅くなることを許可されています。
パーセントは、率をあらわしています。50パーセントは半数が、という意味です。
パーセンタイルは、データを大きさ順でならべて100個に区切り、小さいほうからのどの位置にあるかを見るものです。50パーセンタイルは、小さいほうから50/100のところにあるデータです。
このアプローチはおおむねうまくいきますが、いくつか落とし穴がある。
● このアプローチは、外部ネット経由のように、クライアントにかなりのネットワークの遅延がある場合には機能しない。
このような場合は、クライアントが世界中に広がることを懸念しつつ、合理的かつ最悪のネットワーク遅延のケースを計算に入れておく。
● このアプローチは、p99.9 も p50 も大きな違いがないくらい、遅延の基準値が小さいサービスでもうまくいかない。
このような場合、パディングを追加することで、小さな遅延の増加が、大量のタイムアウトを招くのを防ぐことができる。
パディングとは、詰め物、水増し、埋草などの意味を持つ英単語。ITの分野では、表示要素の内側に設けられた余白や、データを一定の長さに整形するため前後に挿入される無意味なデータなどをこのように呼ぶ。
● タイムアウトを実装するときに、もっともハマりがちな落とし穴は次のようなものである。
Linux の SO_RCVTIMEO は強力だが、エンドツーエンドのソケット（クライアント側）のタイムアウトとしては不向きな欠点があります。
SO_RCVTIMEO と SO_SNDTIMEO
送信・受信のタイムアウトを指定する。これを越えるとエラーを報告する。
Javaのようなプログラミング言語は、このコントロールを直接オープンにする。
他のGoのようなプログラミング言語は、より強固なタイムアウトの仕組みを構築できる。
● また、DNSやTLSハンドシェイクのように、タイムアウトがすべてのリモートの呼び出しをカバーしていない実装もある。
一般的には、ちゃんとテストされたクライアントに組み込まれているタイムアウトを好んで使っている。
独自のタイムアウトを実装する場合、タイムアウトソケットオプションの正確な意味と、どのような作業が行われているかに注意を払っています。
Amazonが取ったタイムアウト問題の回避方法
とあるシステムで、タイムアウト値を約20ミリ秒（約0.02秒）に設定していた
デプロイ以外ではタイムアウトが定期的に発生することはなかったが、デプロイ直後でタイムアウトが見られた
これは、デプロイ時の接続の確率に0.02秒以上かかっていたため、デプロイするとリクエストの一部がタイムアウトしてしまっていたためである
これを解決するために、まずデプロイの場合、接続確率時のタイムアウト値を増やす改善を行い、のちに（どういう意味？）プロセスを開始後、トラフィック受信前に接続の確率を行うよう改善を行った。
再試行とバックオフ
再試行は一時的な障害には有効だが、過負荷が原因の障害の場合は再試行が余計に負荷をあげてしまう（時には元の原因が解決したのに再試行が負荷の原因として残る）。
→再試行は強力な薬に例えている。弱ったところに強力な薬を投与すると、薬に耐えれずかえって体調を崩す、ということか。
そこで、バックオフを推奨。
エクスポネンシャルバックオフ 再試行の間隔を指数関数的に増加させるので、再試行そのものが過負荷の原因になるのを防止する。ただし別の問題が発生する。
そこで、再試行する回数に上限を設け、サービス指向アーキテクチャの初期で発生する障害を処理することで対策している。
その他リスクと課題
● 分散システムの場合
分散システムの各レイヤーごとに再試行を行うと、再試行の回数が大幅に増加して負荷も大きく増加。
スタックの最上位レイヤーで再試行すると、以前のリクエストが無駄になって効率が悪い。
スタックの単一ポイントで再試行するのが一番効率が良い。
スタック（Stack）とは 「分かりそう」で「分からない」でも「分かった」気になれるＩＴ用語辞典より > スタック (stack)とは 後に入れたものが先に出る構造になっている何か
最上位レイヤー ＝ 後に入れたもの ということ？
それを再試行すると、先に入れたものもやり直しになるから、ということだろうか？
● 負荷の増加
エラーのしきい値を超えると端末への呼び出しが遮断されるサーキットブレーカーが便利。
サーキットブレーカーはモーダル（表示されたタスクが完了するまで、ユーザーは他の作業を行えない）を採用していますが、テスト困難で復旧に時間がかかる。
トークンバケットを使用してローカルで再試行を制限することで解決している。
参考）
トラフィック(≒ API リクエスト数)を制御するために利用できるアルゴリズムで、バースト(瞬間的なトラフィック増大)を許容しつつ、トラフィックの平均的な流量を一定以下に保つことができるものである、と理解した。
トークンとバケット 一度に転送可能なトラフィックの最大を『バケット(バケット)』で表現し、トラフィックの転送を許可するための手形を『トークン』で表現する。 ひとつのトークンは一定サイズのトラフィックに対応し、トラフィックを転送する際にトラフィックに応じた数のトークンが消費(削除)される。
● 再試行のタイミング
べき等性がない（＝副作用がある）APIは再試行しても安全ではない。
読み取り専用APIはべき等性があるが、リソースを作成するAPIはべき等性がない。
(Amazon EC2) RunInstances API などの一部の API は、明示的なトークンベースのメカニズムを提供して、べき等性を提供し、安全に再試行できるようにしている。
● 再試行したほうがいい障害かどうか選定
HTTPだとクライアントエラーとサーバーエラーは明確に区別される。
クライアントエラー (400–499) 通常再試行しても成功しない。 サーバエラー (500–599) 再試行すると成功する可能性がある。
ただし、システムの結果整合性により、クライアントエラーでも再試行により成功になる場合がある。
分散データベースの文脈で使われることが多く、データの更新の一貫性を即時担保するものではなく、更新後に一定時間経過していれば正しく更新データを取得できるという整合性の考え方
英語を直訳すると『最終的な一貫性』となり、和訳では『結果整合性』という訳が当てられ、2つの意味を統合すると直感的にわかりすい。
この同期を取るタイミングが様々なパターンがあるが、即時ではなく、時間経過があって何かしらの状態で結果として同じ状態になる状態のことを「結果整合性が取れる」と呼ぶ。
結果整合性のとり方はいろいろあるが、3分毎に複数のDBを同期するなども結果整合性を取るという意味では1つのアプローチと言えるはず。
課題やリスクはあるが、再試行は障害対策として強力なので、賢く使うべき。
ジッター
過負荷または競合が障害の原因である場合、バックオフが非常に役に立たないことがある。
同じタイミングでバックオフされてしまうと、過負荷になってしまうからである。
そこで、バックオフをランダムに行って負荷を分散させる、ジッターを採用している。
ジッターは再試行以外の用途にも使う。
定期的な作業の場合は、ランダムにジッターを行わず、各ホストが同じ数だけ実行するようにする。
ランダムだとトラブルシューティングが難しくなるからである。
まとめ
タイムアウトは、リクエストが長期化するのを防ぐ。
再試行は、リクエストの長期化をなかったことにする
バックオフ・ジッターは、再試行が集中するのを防ぐ。
Amazonのシステムは、負荷の状況や可用性を考慮して再試行を行う。
感想
べき等性、「何度再試行を繰り返してもリソースに影響」させない仕組みとはどういう仕組みだろうか。
なんとかわかりやすい日本語に直してみたものの、まだ血肉にはなっていない感が強い。
改めて見直してみて、補足したい。
以上になります、最後までお読みいただきありがとうございました。
pandasよりも処理が速い（らしい）daskを使ってみた
仕事で重いcsvデータを扱う機会がありましたので、pandasよりも速い（らしい）daskを使ってみました。
ライブラリのインストールは以下のコマンドを入力。
dask のインストール後、ライブラリを回すとエラーが出て python -m pip install dask[dataframe] --upgrade を実行せよと出ましたので、これも実行。
python pip install dask python -m pip install dask[dataframe] --upgrade
dask のライブラリのインポート。
pandas に比べ、心持ち長いですね。
import dask.dataframe as dd import dask.multiprocessing
csv の読込は pandas と全く一緒ですね。 データに合わせてパラメーター sep（区切り文字の指定）や encoding（文字コード）を指定しましょう。
データの表示は、ddf.compute() という pandas では見慣れないものがあります。
こちらは処理を行うためのメソッドのようです。
なお、ddf = ddf.conpute() を入れてやらないと、DataFrame型として出力されませんでした。
この点は、read_csv()だけでDataFrame型が作成可能な pandas と違いますね。
参考 qiita.com
# csv の読込 ddf = dd.read_csv( "任意のデータのpath") # 読み込んだデータの表示（すべての行を表示） ddf = ddf.compute()
すべて実装されているわけではないようですが、一通りの pandas の機能は使えるようです。
参考 qiita.com
データの数字は適当なので、グラフもぐちゃぐちゃです、ご容赦ください。
# 折れ線グラフ ddf.plot("def", "stq")
# グラフの細かい設定 ddf.plot( "def", "stq", title='Iris Data Set', # タイトル grid=True, # グリッド線の有無 colormap='Accent', # 色 legend=True, # 凡例の有無 alpha=0.8) # 透過率
折れ線グラフ以外も出力可能です。
# 散布図 ddf.plot("def", "stq",kind="scatter")
要素の数値計算もできます。
# 合計、平均、最大値、最小値 print(ddf.sum(),ddf.mean(),ddf.max(),ddf.min())
カラムの要素同士を計算して、新しいカラムを作成することも可能です。
# 要素同士の計算 ddf["abcdef"] = ddf["abc"] * ddf["def"] ddf
欠損値(NaN)の処理もできます。
# 欠損値のカウント
ddf.isnull().sum()
# データ型が数字の列のNaNを平均値で埋める ddf = ddf.fillna(ddf.mean()) # 残ったデータ型が文字の列のNaNの行を削除する ddf = ddf.dropna() # 再び欠損値をカウント ddf.isnull().sum()
軽く機械学習も回してみました。
データが適当に作ったものなので、スコアは全く振るいませんが…。
# サポートベクターマシン（回帰） from sklearn.svm import SVR # データ分割ライブラリ from sklearn.model_selection import train_test_split # 目的変数と説明変数の設定（仮 適当に決めてます X = ddf[["def", "jkl", "mno", "pqr", "stq", "yz"]] y = ddf["abc"] # データの分割 X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42) # SVR モデルの作成 model = SVR() # モデルの学習 model.fit(X_train, y_train) # モデルのスコア model.score(X_test, y_test)
結果はひどいものですが、機械学習のモデルを回せることはわかりましたw
以上になります、最後までお読みいただきありがとうございました。
参考サイト
転置をうまく使ってグラフ化する
pythonで、転置をうまく使ってグラフ化する手法を学んだのでまとめました。
次のようなDataFrame型のデータ（df）を想定します。
player（選手）の、1days_score（1日目の得点）、2days_score（2日目の得点）、3days_score（3日目の得点）をまとめた表です。
これを、各選手が日ごとに何得点を獲得したかをグラフ化したい場合を想定します。
そのままグラフ化してみましょう。
df.plot()
するとこのようなよくわからないグラフが表示されます。
これは1days_score、2days_score、3days_scoreがカラムになってしまっているためです。
こういった場合、転置を使うと、うまく選手ごとの日ごとの得点グラフにすることができます。
併せて、このまま転置をしてしまうと、indexの1、2、3がカラムになってしまいますので、index_set()でindexをplayerに変更しておきましょう。
df.set_index("player").T
行と列が入れ替わった表を作ることができました。
df.set_index("player").T.plot()
選手ごとの日ごとの得点グラフ化に成功しました！
以上になります、最後までお読みいただきありがとうございました。
参考サイト
Amazon Builder's Library 継続的デリバリーによる高速化 を読んだ
輪読会に向けて、Amazon Builder's Library（以下、ABL） を読んだので、簡単にまとめてみました。
テーマは「継続デリバリーによる高速化」です。
書いたのは、Amazon Web Service のソフトウェア開発のシニアマネージャーの方で、項目は、以下の4つでした。
はじめに
パイプライン：継続的デプロイツール
欠陥によりお客様に影響するリスクの削減
実行速度へのアプローチ手法
それでは内容について触れていきたいと思います。
はじめに 継続的な改善とソフトウェアの自動化
（AWSの広告？ 笑）Amazonはリーダーのためのプリンシプルを掲げ、開発者ツールを構築し、実行速度の改善を常に図っている。
パイプライン: 継続的デプロイツール
リリースのプロセスを手動からパイプライン処理に変えたことで、プロセスを高速かつ簡素なものに出来た。
パイプライン構築チームは、”魅力的な採用（原語 seductive adoption）”によるAWSの利用数増加を年間目標にしていた。
英語独特の表現なのか、ABL日本語版のわかりにくい訳なのか。
補足 ”魅力的な採用（原語 seductive adoption）” は、顧客を引き付けるような仕組みをAWSに取り入れること、か？
これは私の感想ですが、顧客の増加ではなく、仕組みを取り入れることが目標になっているのは、投資に積極的なAmazonらしいですね。
Amazonは短期的な結果のために、長期的な価値を犠牲にしない理念を掲げている。
テストに時間をかけすぎて他社にリリースに後れを取らないようにすること、一方で開発からチームが学べるようにテストが行えるように、テストを自動化した。
欠陥によりお客様に影響するリスクの削減
リリースしたサービスに欠陥があった場合、早く欠陥を特定し、顧客に影響を与えないために、以下の仕組みをとっている。
デプロイメントハイジーン
補足 聞きなれない言葉だが、デプロイの環境を整えること？
ITハイジーン（IT Hygiene）のハイジーンとは少し聞き慣れない英単語ですがどのような意味なのでしょうか。
英和辞典では衛生状態や衛生学と訳します。つまりエンドポイントの「衛生状態」を管理するものと捉えると理解が進むと思います。
デプロイ時にトラフィックを確認する。
ライフサイクルイベントフックを使って、デプロイを停止、開始、有効化するためのスクリプトを動かしている。
（参考）Amazon EC2 Auto Scaling ライフサイクルフック
ライフサイクルフックを使用すると、Auto Scaling グループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行できます。
インスタンスが一時停止されると、complete-lifecycle-action コマンドまたは CompleteLifecycleAction オペレーションを使用してライフサイクルアクションを完了するまで、またはタイムアウト期間が終了するまで (デフォルトでは 1 時間)、待機状態のままになります。
容量を確認したり、障害が発生したら新しくリリースした内容をロールバックする仕組みがある。
実稼働前のテスト
（AWSの広（ry ）実稼働前にあらゆるテスト（負荷、セキュリティ、コード等）を自動的に行っている。
実稼働システムと同じ構成を使うので、製品版とまったく同じ動作をさせてテストも行っており、二つのメリットがある。
① すべての製品リソースと適切に接続することを確認できる。
② そのシステムが、動作に必要な実稼働サービスの API と正確にやり取りしているかを確認できる。
Validating in production
デプロイは一度にせず、サービスの中で完全に独立したインスタンスごとに行う。
テストを構造化し繰り返し行うことで、すべてのエラーを発見できるように努力している。
新しい変更内容を決まった期間だけ製品の中に放置し、チーム以外のメンバーが何かの問題を発見するか確認している。
1 分ごとの疑似トラフィックを作って、テストを行ってい、実行中のプロセスが正常であるか、またすべての依存関係 (公開 API も含む) を確認する。
ソフトウェアリリース時期の制御
パイプラインを介してリリース時期を制御できるメカニズムを構築している。
指標の管理やデプロイ等の時間の管理、パフォーマンスの管理をしてデプロイを制御している。
実行速度へのアプローチ手法
AWS は自動化、リリースのスピードアップに取り組んでいる。
感想
AWSの宣伝半分で聞き流したとしても、AWSの機能改善に膨大なリソースを割いていることがうかがえた。
システム的なことよりも、それを可能にしているAmazonの企業理念であったり制度が気になったので、ベソス・レターをポチって見ました。
そのうち書評をアップしたいと思います。
以上になります、最後までお読みいただきありがとうございました。
