ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

英会話2019/9/10

ビジネス 電話応対 Making a Reservation

レッスンで使われたセンテンス

  1. It is important to make a reservation to make sure that a table is ready and available.
    • make sure 確実にするという意図で自分で調べて使った。覚えたい。
    • make a reservation、自分の語彙になかった。覚えたい。
  2. Some restaurants refuse to accept reservation to be able to accommodate walk-in guests.
    • accommodate: 調整する、これも語彙になかった
    • walk-in guests, なるほどと思った 突然来たひと、みたいな表現をこちらがすると教えてくれた
  3. I consider the ambiance if it is conducive to conversation.
    • ambianceになるんだなあ。レストラン予約するときにどういう点を考慮する?って質問で、会話を重視するから静かなところがいいって言ったらこうなった。
    • conducive, いまいち意味がしっくり来てない。。。

レッスンで使われた単語

1 walk-in guest
2 ambiance

Useful Expressions

  • I would like to make a reservation.
    • make a reservation, 覚える
  • Are there any tables available for Friday night?
    • 予約、レストランの場合はtableが使えるか、という表現になるんだね
  • I would prefer 8 pm.
    • 何時がいいとき、希望という意味でpreferなんだ(wantではない)

その他

  • suit 発音
  • reserved 発音 濁らない?濁ってもいい
  • he made a dinner reservation
  • participants: a person who takes part in something.
  • accommodate 意味
    • (of a building or other area) provide lodging or sufficient space for.
    • fit in with the wishes or needs of.
  • walk-in guests. 当日くる客
  • ambience 雰囲気?
  • conducive: making a certain situation or outcome likely or possible.
    • I consider the ambiance if it is conducive to conversation.

感想

内容は普通にお店を予約するときと同じ。機会はしばらくはないが、ある程度の期間、英語圏で過ごすなら絶対に必要になりそう。

この日の講師はテンポが良く、最後まで行き着いたし、ロールプレイも順調だったのでよかった。ロールプレイとディスカッションが一番タメになるので、自己紹介は省略してもいいかもしれないと思いはじめた。雑談も面白いんだけどね。

英会話2019/9/9

ビジネス/電話応対 Asking for Information

レッスンで使われたセンテンス

  1. He was interested in buying one of their new product.
  2. He called to inquire about the features of a new product.
  3. I'd like to order some tables and chairs.

レッスンで使われた単語単語一覧を見る

  1. bulk
  2. the mass or size of something large.
  3. the greater part of something.
  4. "バルクインサート"のそれか
  5. check or cheque
  6. an order to a bank to pay a stated sum from the drawer's account, written on a specially printed form.
  7. 小切手。知らなかった。

注文するときの便利表現

  • I'd like to inquire about...
  • I'd like to know more about...
  • I was wondering if you could give me some information about...

その他

  • Davao City: フィリピンで3番目の都市とか。
  • 教えてくれて・伝えてくれてありがとう的なとき、Thank you for ~ing で言おうとしてtellingとかなりがち
    • Thank for the information about your tables and chairs.
    • Thank you for the information便利なので使いたい
  • I'd like to order 8 sets tables (desk) and chairs
    • まんまだけど 数字 sets ~s and ~s
    • 机と椅子の組み合わせをいくつ

感想

  • 22日毎日欠かさずできていてえらい
  • 一方、復習が全くできておらず、受けっぱなしになっているので効果が半減していると考えた
  • 英語学習1on1で「せっかく習慣化できているのだからそれにくっつけた方がいい」とアドバイスをもらい、レッスンを受ける前に前日分を復習することに
    • どのみち朝起きてから予約しているので、予約してから受けるまで20分-30分ある時間を使うことにした
  • 復習の質は今後考えるとしてひとまずやれたので嬉しい
  • レッスン中にでてきたわからん単語や表現はメモに控えるよりその場でremin.doに突っ込むのが良さそうだ

データ指向アプリケーションデザイン読書メモ:1章

今日16時から社内勉強会やるよー!

普通に書いてる分は運用で、(chaspy)がお気もち

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

  • 多くのアプリケーションは演算指向ではなくデータ指向
    • CPUの演算能力より、データをどう扱うか、がボトルネックになりやすいことを示す
      • データ量
      • データが変化する速度
  • 本章ではデータシステムで以下の課題をどのように解決するかを考える
    1. 信頼性
    2. スケーラビリティ
    3. メンテナンス性

信頼性

  • 何か問題が生じたとしても正しく動作し続けること
  • 問題を起こしうるものをfaultと呼ぶ
  • faultによって、システム全体がユーザにサービスを提供できていないことを障害(failure?)と呼ぶ
  • 障害には大きく以下の3つに分けられる
    1. ハードウェア障害
    2. ハードウェア障害は常に起きる
    3. 通常RAIDなど冗長化していて、fault traranceを持つ
    4. 仮想マシンというレイヤーで考えても、AWS EC2インスタンスが使用できなくなることもある(chaspy)
      • メンテナンスのため再起動が走ったりもする(chaspy)
      • クラウドを使う上でも、落ちてもいいように設計すべき(chaspy)
    5. ソフトウェア障害
    6. システム内でのシステマチックなエラー
      • ソフトウェアのバグ、特定の入力があるとクラッシュする、など
      • プロセスの暴走によってリソースを使い切る
      • 依存するサービスの問題
      • カスケード障害
    7. 解決策は?->ちょっとした積み重ね
      • 徹底したテスト
      • プロセスの分離
      • プロセスのクラッシュと再起動の許容
      • 計測
      • モニタリング
      • プロダクション環境におけるシステムの挙動分析
    8. このあたりはReadiness Check / 負荷テストでサービスインのときに把握できるようにしたい(chaspy)
    9. ヒューマンエラー
    10. 人間には信頼性がない
    11. 人間はスケールしない(chaspy)
    12. ではどうするか?複数のアプローチを組み合わせる
      • インターフェースによって正しいことを行いやすく、間違ったことを行いづらくする
      • サンドボックス環境をプロダクションと分離して提供して経験を積む
      • すべてのレベルで徹底的テストを行う
      • 設定のロールバックを即座にできるようにする
        • これは1番大事だとQuipper SREに入って学んだ
      • 詳細で明確なモニタリングの仕組みをセットアップする
      • 優れた管理方法とトレーニングを実践する
  • 信頼性の重要度
    • これ最近考えているテーマだった。何かしらで重要度をつけてRediness Checkを軽くしたりできないかなあと(chaspy)
      • SLOを低く、あるいは設定しない、というふうにするのも一案かなあと思うが悩む(chaspy)
    • アプリケーションが「クリティカルではない」ものであったとしてもユーザに対する責任は発生します
    • 信頼性を犠牲にすることで、開発コストを下げたり、運用コストを下げたりする場合もあるが、その場合信頼性を犠牲にしていることを強く意識しておくべき

スケーラビリティ

  • 負荷の増大に対してシステムが対応できる能力
  • どのようにコンピュートリソースを追加すれば負荷に対応できるか?
  • Twitterの事例
    • ホームタイムラインの取得の際の負荷の問題
      • 読み取り時の処理を少なくし、書き込み時の処理を多くした(書き込み頻度のほうが2桁小さいので)
    • また、極めて大量のフォロワーを持つユーザは最初のアプローチをとり、ハイブリッド型とした
  • パフォーマンスの表現
    • スループット
    • レスポンスタイム
      • 通常外れ値があるので、mean(50 percentile)、95 percentile, 99 percentileを使う
      • 99 percentileはテイルレイテンシ、ユーザ体験に影響していることが多い
        • Amazonの例では99.9 percentileを指標にしている
        • 1/1000しか影響しないが、そのユーザは大量に購入しており重要な顧客である可能性が高い
        • この考えは自分にはなかった、遅いから気にしなくていいと思ってた(chaspy)
        • レスポンスタイムと売上の相関が見れると良いな、うちでいうとどうだろう?学習継続率とか?(chaspy)
  • 負荷への対処のアプローチ
    • 負荷が10倍になったとき、アーキテクチャを再考する必要があるだろう
    • スケールアップとスケールアウトがある
      • 実際、直近はMongoDBをスケールアップした(chaspy)
      • MongoDB自体はスケールアウトの仕組みを持っているが、複雑度が増すため見送っている(chaspy)

メンテナンス性

  • 3つの設計原理
    • 運用性
      • 運用者が扱いやすいものにする
      • 個人の出入りがあっても、システムに関する組織の知識が保たれるようにする
        • 大事だと思う(chaspy)
      • デフォルトの挙動を優れたものにする
      • 総じてドキュメンテーション、自動化、コード化がこれらを支えると思う(chaspy)
    • 単純性
      • 偶発的な複雑さを取り除くこと
      • 優れた抽象化をする
    • 進化性
      • アジリティのこと
      • 運用性、進化性に大きく依存する

まとめ

  • ソフトウェア・システムには機能的な要求、非機能的な要求があり、後者のうち信頼性、スケーラビリティ、メンテナンス性を取り上げた
  • これらを簡単に高める方法はないが、くり返し現れるパターンやテクニックは存在する
  • 今後の章でデータシステムがこれらの目標にどのように向かっていくのか考察する

感想

  • SREとして働く上でもっとも重要な3つの概念を改めて言語化、整理されていて非常に良かった
  • SLOを定める上でパフォーマンスの表現の章が密接に関わる。レイテンシは複数のパーセンタイルで分析したいと思う。
  • スケーラビリティ、メンテナンス性はReadiness Checkでのアーキテクチャレビューで担保できるようにしたい。現状アーキテクチャレビュー、事後の説明になってしまっていてあまり効果的に働いていないので
  • メンテナンス性に関しては経験を持った個人に依存している部分も多くあると思っており、課題を感じている。ドキュメンテーション、コード化のいいバランスを考えたい。(すべてをドキュメント化すべきだとはもちろん思っていない)

勉強会終わったあと追記します。

datadog-aws-ec2-counter はべんり / OSSへContributionすること

はじめに

べんり

github.com

最近クラウドのお金まわりと"ちゃんと"しようとしていまして。Quipper では以前よりこの datadog-aws-ec2-counter を利用してインスタンスの使用状況を可視化しています。

これは Instance の hootprint の数値が Reserved Instance と Ondemand instance でそれぞれとれるスグレモノで、利用的には Ondemand instance で長期間動いているものは Reserved Instanceを買うべきですし、Reserved Instanceを買っているが使っていないものがあればそれはもったいないということになります。

AWS、Reserved Instance を買う行為自体めちゃくちゃしんどいですし、(UI的な意味でも、高額で間違えられないという意味でも)Reserved Instance を買う前の計画を立てるためにもとても有効なツールです。

Pull Requestを送った

ある日、突然これまでとれていた metrics が取れなくなってしまっていて、原因を調査したところ簡単な修正で治ったので Pull Request を送りました。

github.com

メンテしていた @mounemoi さんがまだ在籍されてるか不安だったので、mixi SREの清水さん @isaoshimizu に連絡したところ、見ていただいてマージしてもらえました。いい話だ。

OSS にシュッとPRを送ること

一応職業プログラマ、ソフトウェアエンジニアとしてn年働いてるわけですが、「OSS に Contributeする」というのは自分にとってとてもハードルが高い行為で、「やりたいんだけどできない。できるようになりたい」とかなり長い間思っていたような気がします。これをふつうに、というか、できるものとできないものはあるでしょうが、やろうと思うハードルが低くなったのは、そして実際にやれるようになったのは直近の1、2年です。

新卒当初は Rails の内製のソフトウェアを開発していました。Rails はもちろん OSS だし、使う gem ももちろんそうで、やれてもいいものですが組織内にまったくそのような文化がなく、その発想すらなかったように思います。

そしてその次が OpenStack で、このときは組織として Contribution していくぞ、という雰囲気があったんですが、お作法がわかってなかったり、取り組むステップがわからなかったり、何しろ大規模であるということ、Python に習熟していなかった(これは言い訳っぽいな)こともあり、このあたりで意識は芽生えるものの全然行っていませんでした。社内にはトップ Contributer も在籍していたので、今思えば教えを請えばよかった話なんですよね。そのひとがメンターで見たインターン生が OpenStack にパッチを出していて情けない気持ちになったのを思い出したりしました。

もちろんいまでも大規模な、例えば OpenStack や Kubernetes の内部へ Contribution するのは"すぐには"できないでしょう。しかし、Terraform AWS Provider へいくつか Contribution した経験を通しても時間をかければできるところはあるだろうし、それ以外のDocumentや、非常に簡易な修正でも、いくらでも貢献方法はあるわけです。

合わせて重要なことはなるべく最新版を使う、そのためには定期的な Upgrade を "ちゃんと" やるというのも、難しいですが非常に重要な点だと思います。

OSS を使って困ったことに遭遇したら

  • まず upstream を見る、cloneして、grepして、コードを読む
  • 直せそうか考えてみる
  • 難しそうであればissue、または一部分だけでもPRとして出す
  • 詳しいひとに相談する

こういう小さい、でも当たり前のことの繰り返しでそれはできるし、こういうハードルを下げればいいだけなんだなぁと、実感するばかりです。でも昔から今もこういうことは多く発信されてると思うので、なんで自然とできるようになったかというと、OSSで見つけた不具合を大小、ロジック・ドキュメント問わずさっとPRを出す、そういうことを当たり前にできる仲間が多い環境にいるからで、やっぱり環境は大事だと再実感するのでありました。

人生にはこういう「その状態に達してみないと気づけない、しかし重要なこと」が多くあり、だからこそチャレンジが大事だな、とも。

おわりに

Growth - Hack the growth curve for you and your team We all have a passion for learning. Stay curious and thirsty for new things, and don't be afraid to take a leap. Always keep yourself out of the comfort zone.

Always keep yourself out of the comfort zone

Growth は Quipper の 5 value の1つです。

英語週報8/18~週

英語週報つけることにした。1年頑張ろうな。 すでに遅れてるんだけどね。

どうしたの急に

8/18に一念発起した。

約1年前に英語を"前職よりは使う(ただしメインはテキストの読み書き)"という環境に転職したが、特に英語力は伸びていない。なぜかというと勉強してないから。英語力ってなんだって話はいったんおいといて。

「やらなきゃなー」で甘えてたんだけど、ソフトウェアスキルへの投資を少しでも緩めるのが怖い、ということを言い訳に着手していなかった、ことに気づいた。それはやはり優れたソフトウェアエンジニアである同僚が毎朝習慣的に英語学習をしていることを知ったからだ。「習慣にしてますね。」自分の甘さに気づくのはこの一言で十分だった。

そんなこんなで論理をすっ飛ばしてとにかくやれ、ということでいろいろ手を出しつつも、最低限オンライン英会話は毎日やる、ということを決めた。もちろんこれだけでは足りないので随時足していくしいろいろ試していく。

英語が優れている仲間たちに英語を勉強していること、勉強の方法について相談したら、基礎が遠回りに見えて近道なので、まずは英検2級を問いてみてはどうか、それがスラスラ解けるならより高いものを、そうでないなら基礎を固めたほうがいい、という趣旨だった。

高校卒業程度の3000単語の語彙あるいは基礎文法がないまま英会話するよりは先にそれを固めたほうがいいというのももっともだし、何かしら今の実力を継続的に測定したり今の自分の位置を知る手段がほしいと思っていた。(英検はpass or fail の2択なのでなんともだが)10月に受けることにした。あっさり受かるならそれはまぁそれでいい。

LTで退路を断ったり、前述の尊敬できる同僚に1on1でのコーチング、メンタリングをお願いしたり、チャットでワイワイしたりして退路を断って、ひとまず10日間続いている。すごい。

とりあえず1年やりきれば絶対に何かしら効果は出ると信じてやる。もちろん、盲目的に1つのやりかたをやる、だったり、ただ無為に英会話25分を過ごすだけにするつもりもなく、そのための週報だったり1on1での振り返りはしっかりしていく。

ちなみに意外とできた!って話かというとそうではなく、"ちゃんとしんどい"です。英語は楽しくやるのがいいとか、それはそうなんだけど、ちゃんと仕事はしないといけないわけで、幸運なことに(?)決して仕事がヒマではないので、変わらない仕事の負荷は継続しつつ英語の勉強をしないといけなく、覚悟はしていたものの"ちゃんとしんどい"です。とはいえもうやりはじめたのでやりきりますが。

ゴールはなんだっけ

  • 海外カンファレンスでディスカッション、あるいは質疑応答ができること
  • Software Enginnerとしてできないと成長を阻害する(後ろ向き)
  • 仕事をする上でできないと成長を阻害する(後ろ向き)

というわけで、やっぱりSREConに行ったことはたしかに次につながったわけで(ちょっとラグあったけど)コンフォートゾーンから出ることの重要さを実感するばかりです。

blog.chaspy.me

強く思ったことは、強くなってまたここに(厳密に同じSRECon Asiaという意味ではなく、海外カンファレンスという意味で)帰ってきたいということだ。

振り返り

このへん。

なんかいろいろ手法とかあるけど、シンプルにこの量を増やすことが本質的で、加えてスピーキングでは言いたいことを結びつける作業をすればいいと思う。だから、ただたんにDMM英会話をするだけじゃ効果は半減なのは言うまでもない。「これ言いたいから調べさせて」と言ったら快く待ってくれるのがありがたい。教材を使っても1回に数個は知らない単語は出てくるので、その音と一緒に覚えることができる。これはやってみいないとわからないことだった。やっぱり人生はやってみないとわからないことが多い。

ちょっと細かい英語の振り返りもするつもりだったけど遅れているので決意表明まで!来週からちゃんと書くぞ。

Alibaba CloudにISUCONの模擬試験環境を構築する(Terraform編)

はじめに

した。

github.com

さて、今年もISUCON出ます。去年何もできなかった自分に対して圧倒的な成長を実感できる予感がしています。

チーム内でいろいろ作戦会議をしてますが、最初の30分それぞれ何をするのか、そして実際にできるのかの模擬練習をしておいたほうがいい、という意見が出まして、ヨッシャ環境構築するぞとなりました。

Alibabaもalicloud providerもはじめてでしたが、なんやかんやでとりあえず1台インスタンスが立ってGlobal IPにsshできるところまできました。

事前準備としては - Terraform userの作成、Administrator権限の付与 - keypairの事前登録、keypair名をtfファイルに更新

ができれば動くはずです。 ちなみにちゃんとTerrafrm 0.12.6にしました。ちゃんとした。

Alibaba Cloud、普段クラウド触ってればだいたい雰囲気同じ感じでなんとなしできると思います。

ユーザに関しては Resource Access Management -> ユーザ -> 新規ユーザで。Administrator グループを作ってそこにterraformユーザをいれてあげる。そのグループに権限付与ポリシーでAdministratorをあてる、だったはず。 まぁAWSのユーザ、ロール、ポリシーと同じノリです。

新規ユーザ作成時にkeyとsecretが生まれるのでそれを.envrcにいれて環境変数で読めるようにしましょう。

$ cat .envrc.sample
export ALICLOUD_ACCESS_KEY="secret_secret"
export ALICLOUD_SECRET_KEY="secret_secret"
export ALICLOUD_REGION="ap-northeast-1"

keypairですが、新規に作るのも面倒なので、自分のGitHubに登録してある公開鍵を使って https://github.com/chaspy.keys 既存のkeyをimportする形にしました。 そのkeypairの名前だけterraformの keypair attachment resource にいれてあげる必要があります。

resource "alicloud_key_pair_attachment" "attachment" {
  key_name     = "key_pair_github" # Create key pair by hand
  instance_ids = ["${alicloud_instance.web.id}"]
}

Applyするとoutputにglobal ipがでるので、sshすればよいです。

余談だけど普段ラッパースクリプトとかCIとかでしかTerraform実行しないので terraform ってフルスペル入力するのしんどくてエイリアスした。。。

$ tf apply
(snip)
Apply complete! Resources: 11 added, 0 changed, 0 destroyed.

Outputs:

ip = 47.74.4.123

$ ssh root@47.74.4.123

Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-52-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


Welcome to Alibaba Cloud Elastic Compute Service !

root@isucon8:~#

おそうじも簡単でらく。

$ tf destroy
(snip)
Destroy complete! Resources: 11 destroyed.

このあと複数台構成にするとかいろいろやるかもしれない。

次はAnsibleでApplicationを構築するところをやります。いうて以下を流すだけになると思うが。

github.com

おまけ

alicloud-providerに軽微なPR2件出した。マージされろー。

github.com

github.com


追記。された!

delete branch botというGitHub Appをクローズした

はじめに

した。

github.com

ついにGitHubオフィシャルでPRをmergeしたあとbranchを削除する機能が出たからだ。

help.github.com

作ったときの記事

blog.chaspy.me

少し残念な気もするが、個人のリポジトリで1年弱、何の問題もなく安定稼働していたし、lambdaでまともになにか作ったのも、GitHub Appを作ったのもはじめてだったのでいい経験になった。

datadogでどれだけ呼ばれたかは監視をしていて、これを機に確認してみた。

f:id:take_she12:20190818131305p:plain

なにげに使用数は少しずつ最近は伸びていて、多いときに1日500回ほど呼ばれていたようだ。そういや会社の一部のリポジトリで「branchを消す文化」のないところがあったので入れたのもあったかもしれない。

このDashboardも削除した。

サービスだったりアプリケーションを「ちゃんと」クローズするのも大事だと思うので喜んでバイバイした。

またなにか誰かに使われるものを作れたらいいな。