21世紀少年少女はVRの夢をみるのか

ゲームセンターあらしは『VR』の夢をみるのか？！

「Game Tools & Middleware Forum」通称"GTMF"に参加しに 大阪に来ています。PlaystationVRに釣られてやってきました。 周りはゲームエンジニアさんやゲームエンジンを作っている人や ミドルウェアを作っている人ばかりで、 サーバのインフラとしては場違い感しかありませんが、 やっていく精神で頑張っていきたいです。 前夜祭として「ゲームセンターあらしは『VR』の夢をみるのか？！」という題で セッションがされていました。 登壇者は以下の人達です。

• 菅谷充
  • 漫画家、漫画原作者、小説家、京都精華大学マンガ学部キャラクターデザインコース教授
• 吉田修平
  • 株式会社ソニー・インタラクティブエンタテインメント ワールドワイド・スタジオ プレジデント
• 下田純也
  • エピック・ゲームズ・ジャパン デベロッパー・サポート・マネージャー
• 矢野浩二朗
  • 大阪工業大学情報科学部 准教授
• 黒川文雄
  • 主催・司会　ナビゲーター・コメンテーター

下田さんはUnreal Engineの方で、吉田さんはPSVRの偉い50代男性で有名ですね。

登壇者の人たちの平均年令が50前後なんじゃないかなあと思ったので、 ゲーム業界ってインフラ業界に通じるものがあるのかなあと思いました。

セッション内容として面白かったのが漫画家の菅谷さんのトークでした。映画の視点、漫画の視点から見る VRの視点について語られていて面白かったです。レイモンド・チャンドラーの作品を映画化した湖中の女の話と、 ゲームセンターあらしの構図による視点の話をされていて、いままでは人間の視点がずれて酔ってしまったが、 VRは人間の目線・視線にズレがないので酔わない技術でもあるそうです。 VRなら一人称の視点から他視点も表現可能で、360度のマルチ視点が表現可能なので、 どんなゲームができるか可能なのか期待していきたい。 また、デジタルキャラの存在感がVRで迫力がすごいと言われている、今までのゲームが視聴型であれば VRは目撃者、体験者になるゲーム。 リアルタイムレンダリングとCGエンジンと映画のお話も未来感あってよかったです。 マイケル・ベイやスティーブン・スピルバーグもVRに興味を持っているらしいです。 ルーカス・フィルムとILM（Industrial Light ＆Magic）、そしてスカイウォーカー・サウンドが設立したVRなどの新技術専門スタジオの ILMｘLABがスターウォーズの世界をVRで表現しているので、映画の世界でもVRが導入されるのでしょうねえ。 3DがVRになり、今の4DXと合わせると映画館ももっとやっていけるなと思いました。 ソニーの吉田さんはPSVRの期待を受けて、一社で頑張るのは難しいとおっしゃっていましたので、 もっとハードやソフトがでてくるといいですね。 ただ、VRにも問題点が言われていて、VR空間でもハラスメントは受けることがあるらしいです。 ROであった見抜きいいっすかに通じると思いました。 ただ、文字のハラスメントとVRのハラスメントでは与える影響が全然違うらしいです。 実際にVRで体験できるものとしてはAcross the Line"（『ラインを超えて』）という、 中絶反対派の本物の音声を実体験できる、7分間のバーチャル体験プロジェクトは かなりショッキングな体験ができるらしいです。 VRは目撃者、体験者になるということがわかりやすい作品だと思います。

前夜祭懇親会

PSVRの吉田さんにこっそり質問したのですが、PSVR買うのにPS4.5を待ったほうがいいですかと聞いたら、 PS4.5なんてないから待たなくていいとおっしゃっていました。4kに対応したPSは開発しているが、 秋にPS4.5が発売するなんてSonyとしては言ったことがないとのこと。 これは信じていいのかなあああ。 あと、VRは今までのゲームとは全く違うインパクトがあると思ったので、 日本ではポルノ、アメリカでは銃のゲームでVRでこれらを体験するのは 今までのゲームとは比べられないほどの影響を人体や脳に与えるのではないか、 そうなった時、ドローンのように表現規制されるのではないか、そこに懸念がないか質問をしてみましたが、 レーティングで規制しているから大丈夫、Sonyからは発売させないと言っていました。 ただ、今までのレーティング基準でいいのかなあと疑問は残っています。 わりかし、死人や怪我人がでるぐらいのインパクトがVRにはあると思っています。 CEROレーティング18才以上ばっかのソフトが出て、少年たちができない未来はこないで欲しいなあ。 OculusRiftやPSVRみたいなハードが500万台くらい出荷されて業界が賑わってほしい。 現状日本ではVRはアダルトコンテンツの人気が圧倒的と言われていて、 サマーレッスンで現実世界逃避待ったなしでしょうね。 ただVRで期待しているのはサマーレッスンで日本人の英会話能力が圧倒的成長することに期待しています。 エンジニアとして参考になったのはBISHAMONの後藤さんから伺ったゲーム制作についての勉強方法です。 コードは本からよりリファレンスを調べて書いていくのがよい、ということと 最新の論文を読むことが大事。MLに登録して最新の情報をキャッチアップをしていくのが大切とのことでした。 ここに書いてある論文は読んでいくのがいいと、サイトを教えていただけました。 「英語をやっていくのが大事、みんな英語頑張っている」と言っていて、英語頑張っていきたいと思いました。 早くサマーレッスンやりたいですね。

今回やってよかったので、企業がやっていることを事前に把握していると 名刺をもらった時に反応ができるので、これは大事だなと思いました。

まだ前夜祭なので明日もやっていきます。

【報告】YAP(achimon)C::Asia Hachioji 2016midの感想【二日目】

ブログを書くまでがYAP(achimon)C。 夜中までブログの感想を書いていたら寝るのが遅くなりましたが、 午前中に起きて参加に成功しました。 楽しかったカンファレンスだったので、みなさんもブログ書いていきましょう！

参加したセッション

• スマホ時代のBotアプリのつくり方
• セキュリティテストサービスを開発運営してきた2年間
• このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる
• AIって言葉流行っているけど、実際どう組み込むのさ？
• 出張版MySQL Casual - クラウド時代のMySQL構築運用を考える 2016夏
• kubernetes を使ってサービスを加速させる取り組み
• ユニクロの レジから学ぶ goroutine
• Webサービスにおけるキャッシュ戦略
• [LT]身近に潜む tokenize 2016 ver
• [LT]ES6/Reactが当たり前の現場に入って感じたこと
• [LT]Vagrantであっぷあっぷした話など
• [LT]やる夫はPerlを学ぶようです
• [LT]新米エンジニアの育て方
• [LT] ES2015 の class でアプリケーションを書いてみた話
• [LT]レゴでベルトコンベアーを作り、異常検知をやってみた
• [LT] aruduinoでPCの電源ボタンを押してみる

セッションの感想

• スマホ時代のBotアプリのつくり方

https://speakerdeck.com/yusukebe/sumahoshi-dai-falsebotapurifalsetukurifang

LINEとFacebookのメッセージアプリにBOTという概念と実装が入ってくるというお話でした。 メッセージのやりとりというものはプライベートなものなのに、そこにBOTが入ってくる。 BOTAPIを使ったお話を聞けました。 まずBOTとは人間のように振舞うコンピュータの総称で、 公式APIドキュメントには和訳もあるらしい。BOTを作成して最初の友達追加は50人だが、 申請すれば5000人まで追加できるようになる。 BOTはBOT対1ユーザのインタラクションになるとのこと。 midといものがあり、個別BOTアプリにとってのユーザー識別子で、 midを保持して一斉送信なとができるがフィットしない。 また、ボタンを組み込めて、ボタンを押すとユーザに特定の発言をさせることができるので、 それを受け取って続きの処理をしたりできる。 リッチメッセージとテキストメッセージ、画像メッセージがある。 リッチメッセージは全て画像で、座標で矩形を指定してアクションを決められる。 すごいと思ったインタラクションは、 指定した文字列を発言させるコマンドなど、タップしたら指定した文字列を発言させるといものがあって、 この情報はSDKのソースにのみ載っているとのことでした。 公式ドキュメントだけでなく、ソースを読むことが大事って言うことがわかりました。 自前BOTアプリはcallbackを受け取り、メッセージに含まれるmidを取得しmidめがけてメッセージ(JSON)を返す。 LINE BOT SDKはLINEのGithubがあるので使ってみましょう。 リッチメッセージの作成や署名の検証も一行で書けるし、テストも載っています。 LINEからWEBサーバのforkしたプロセスが画像生成を兼ねる。 Imagerで画像作成し、memcachedにデータをキャッシュさせている。 midをベースにセッションIDを作成するので、セッション管理ができる。 あとBOTの利用状況をGoogle Analytics でトラッキングすることが可能。

• セキュリティテストサービスを開発運営してきた2年間

安全なWEBアプリケーションの世界のためにセキュリティテストサービスを開発運営しているおはなし。 脆弱性検査にはホワイトボックスとブラックボックスがあり VAddy,owasp zap,burpsuiteなどのセキュリティテストサービスがある。 他にはOS,ミドルウェアの検査などがある。 今回はWEBアプリの検査のおはなしで、 WEBアプリの検査で大事なことはアプリケーションの正しい動作を把握すること。 検査時は正しい動作をしていることを再現させる事が大事。 例えばログインセッション期限、CSRF対策トークン期限など。 継続的セキュリティテストをしていこう。 デプロイ中に適宜脆弱性診断をする。 既存の開発フローに脆弱性診断を導入させて、開発フローに適応させる。 どうやるかはCI連携させて無人運用で、正しい動作を自動で再現させるのを目指す。 また、CIの中で流すと時間がかかるので、検査時間をWEBアプリに絞る。 これらをDevSecOpsと言われている。 DevSecOpsをググっても記事はコンサルベースでソリューションが書かれていない。 つまり開発者向けのセキュリティサービスがない。 なので、セキュリティサービス作ったのがVADDYとのことでした。 gitpush→webhook→脆弱性検査→通知の流れで、Vaddyはフリープランあるとのことなので ためしに使っていきたいな。 海外展開のお話がよかったです。 海外に売ることは隣の家に醤油を借りに行くより簡単だからやっていこうと精神で、 英語対応がもちろん必要でサイト、ドキュメント、ブログ、サポートを英語化。 英語はいろんな業者を比較検討して翻訳者にアウトソースしたとのこと。 ドルの定期決済にする。PayPalは使っていないらしいが理由はよくわからなかった。 文字列や時間をUTF,UTCにするのも大事らしい。 宣伝としてブログURLをReddit,hackerniewsにしたらしく Redditに投稿しまくったらアカウントがbanされたとことですので、気をつけましょう。 あとはまとめサイトに掲載させてsackshareやhttp://devopsbookmark.com にpullrecとばしている。 あとは海外にブースを出して、テーブルクロスとかそれっぽい方がいいというのは知見でした。 あとノベルティやステッカーだけでは人があまりこないが、少なくても深い話ができるからいいとのこと。 お金があるところには勝てないですよね。 あとはサービスをよくするにはミートアップするのがいいとのことでした。 フィードバックはなかなかこないのでミートアップするとカジュアルに聞けたりするとのことですが、 ここはログを取って数値化してくっていうのはできないのかなあと思いました。 やらないことを決めるのが難しいから、全ての要望を実装するとぼやけるので、 チーム内の意識を統一するのが大事とも言っていた。 ここもフィードバックは数値化してやることを決めたほうがよさそうだと思いました。 検査内容を絞り、従量課金をしないというのは、これは日本人には合ってそう。 定額制がいいよね。 リッチなレポート、報告会は提供しないで、基本アウトソースでやっているとのこと。 99 Designs,Intercom,Sndgrid。VAddyはVAddyで検査する。 管理画面を省略するが、サポートは優先度高い。 なぜなら気付きが多いので、定期相談会などもしているとのことでした。 サポートは大事、楽しむの大事、SaaSはいいぞというおはなしでした。

• このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる

今回のベストトークです。

聴衆のアンケート結果でMySQLがほとんどで、次点でPostgreSQLでした。 部屋が人いっぱいで密度がすごかったです。 RDSというかMySQL人気ですね。

データベースの寿命はアプリより長い。なぜならデータベースの中身はなかなか変えられないから。 その分闇も多くなってくるとのこと。 MySQLの型に激怒のはなし。型変換、日付型で正しく認識されない仕様がある。 O/Rマッパーがあるせいとのことだったが、よくわからなかったの調べよう。 MySQLで絵文字の寿司ビール問題はutf8mb4_binを使うと回避できるがバージョンに注意。 MySQLにおいてはNULLではないがNULLでもあることもある。PHPに引っ張られた仕様らしい。 PostgreSQLではpgadmin3の翻訳が酷い話だけど、男は黙ってCUIですね！ 基本的には正規化して、外部キー制約を貼るのがいいとのことでした。 RDSエンジニアはバグとヒューマンエラーから守るのが大事なのでまずはSQL勉強しろとのこと。 データ量がメモリに乗らなくなり、あふれた瞬間遅くなる。
ORMが完璧なクエリを書いてくれるとは限らないといっていた。 MySQLとPostgreSQLの使い分けはどうしているのかなあ。 できることがそれぞれあるから、その実例とか知っていきたい。 あとSQLやRDBの勉強はどうやるのがよいかな。Wordpressの運用とかかしら。 インフラエンジニアがどう学ぶのがいいのか知りたかった、 スロークエリが出ているかとか、INDEXを貼るとしか覚える機会なさそうなんだよなあ。 データの死はサービスの死ですよね。DBがボトルネックになるとWEBサーバ全台死ぬ奴だ。 DBエンジニアはサービスがヒットした会社で必要でスタートアップとかには必要が無いと言っていた。 DBエンジニアは金を持っている会社で必要になるとのことで、 DBエンジニアは仕事に困らないよね〜〜 SQLの勉強はSQL実践入門とアンチパターン、DB実践入門がおすすめ本なので、 本を読んだり経験談からも学んでいけるので、 苦労した話や失敗談を共有していこうというお話でした。 Delete_flag なのに9とかNULLとか入ってるケースもあったので命名大事。 メモリに載せること！データがメモリに乗らなくなって突然DBが遅くなるので。 サイト表示で一ページ目ははやいけど、2ページ以降になるとサイトが重くなるのは だいたいorder by とlimit offsetのせいで、 それは全部読み込んでインデックスきかないから遅くなる。 一ページ目はインデックス効いているが、2ページ目以降は効かない。 それは実行計画ログをみればわかる。スローログだけでなく実行計画ログを見よう。 実行計画とはなんだろうか。 実行計画についてはこちらをみて勉強しよう

• AIって言葉流行っているけど、実際どう組み込むのさ？

AIってなんなのさというおはなし。 MSのエバンジェリストさんが自社サービスと他社さんと一緒にやった事例の紹介。 これからはAI/Big Dataだ！と経営者に言われたエンジニアさん向けのお話でした。

Q:どんなことができるの？ A:例えばInstgramをクロールして自社製品がどんなつぶやきされているかわかりますよ〜

Q:どうやるの？ A:IaaSはやれることが多いが工数はかかる。 SaaSはやれることは画像や音声の認識が得意なAPIをつかうことなので工数は短い。 今回はMSのSaaSのCongnitive Serviceのおはなし。 ただAPIはトランザクション課金なので使いすぎに注意が必要。 他社との事例で安いネットワークカメラ使えば監視カメラと一緒に使える。 アロバっていう会社がやっているサービス。 カメラと顔認識で入店と退店で性別、年齢、店内動線追跡やエリア滞在などログに貯めることできる。 人力でもできるが、バイトが適当に入力したりPOS入力は精度が粗い。 Microsoftっていろんなことしてるんですねえ。。 アロバビューさん事例では監視カメラプラス画像解析による マーケティングソリューションとして来店者の性別年齢をリアルタイム解析するお話でした。 個人でやっていくものじゃなさそうだなあと思いました。 会社のお金でやるものですね〜〜

• 出張版MySQL Casual - クラウド時代のMySQL構築運用を考える 2016夏

MySQL運用のおはなし。MHAは無停止フェイルオーバの一つの到達点とのこと。 クラウド時代はRDS。だが技術的に退化していない？ たとえば料金倍、フェイルオーバーが遅い、 インスタンス変更(スケール変更)にシャットダウンを伴う。制限が多い。 アニメーションがすごいけど、どうやったんだろう。 運用したくないからRDSで退化したというお話でした。 マネージドサービスのRDSを使っていればそうですよねえ。 DBサーバ組んでいくかRDSオーロラ使っていくのか、、 AzureのMySQLのサービスを期待しててと言っていたが、 Azure...

• kubernetes を使ってサービスを加速させる取り組み

https://speakerdeck.com/koudaiii/kubernetes-woshi-tutesabisuwojia-su-saseruqu-rizu-mi

k8s 新規からproductionサービスを公開するにはどれくらいかかるかのお話。 サービスを加速させるには変化に強いインフラ基盤が必要で、どうやって用意するか。 WantedlyではCode wins arguments： MTGするならcodeを書いて検証している。 エンジニアは仮説を考えるよりプロトタイプを作って早く学習する。 営業は5くらい契約をとるなどする。 自動化とセルフサービス化はInfra as codeをすすめて開発の人がコマンドで用意できるようにすれば インフラも開発も自分の仕事を集中することができる。 昔辛かったおはなしで、開発からインフラに依頼が来るとタスクがたまり、 ボトルネックになり、日々のタスクに追われることになっていたらしい。。 その解決するためにはインフラチームの人を増やすと一人一人の力を上げることで解決を図ったとのこと。 どうやって力を上げていったんだろうか。気になるな〜〜 インフラの自動化のお話を聞けた。 ここでついにk8sのお話が！k8sのお話までが長かったけどいい話でしたね！ コンテナとして何が動いているかだけ意識していれば良い世界で、 どのコンテナがどのインスタンスで動いているかわからないからDatadog使って調べる。 くーばーねいてすと読むのか。どういうものかもっと知りたかったなあ。 あとで調べてみよう。

• ユニクロの レジから学ぶ goroutine

goroutineとチャネルのおはなし。 go routeineの並列制御数はCPUのコア数と同じくらいでいいとのことでした。

• Webサービスにおけるキャッシュ戦略

WABアプリケーションレイヤーでのキャッシュのおはなし。 キャッシュの目的はI/Oの効率化で使う。I/Oがボトルネックになる。 いろいろ改善するが、めんどくさい。 キャッシュでI/Oで効率化するが、沼で万能じゃなくて問題もある。 exprireが1時間だと外部のコンテンツが更新されても反映されないので 意図的にキャッシュを適宜更新させないといけない。 引数やクエリを使ったkey生成を透過的キャッシュ。DBIx::ORMapperがある。 cache_clearDB側の更新の反映はexpireしたあとになる。 基本的にはフロントに近いところでキャッシュしてあげるとよい。 過去のISUCONではHTML事前生成してSSIで投稿させて点数を上げる手法が合ったらしく、 inclideさせるとはやい。 cacahe thundering herdグラフ問題がある。 アプリケーションによって戦略が変わっていくので難しそうでした。

• [LT]身近に潜む tokenize 2016 ver

住所、電話番号、市外局番総務省資料の資料(doc,pdf)っていうのがクスッてきた。 S式むずかしい

• [LT]ES6/Reactが当たり前の現場に入って感じたこと

突発の勉強会とコードレビューやってくれるっていうのがよいなあ。 コミュニケーションをとって教えてくれるというのは大事ですよね。 人ははやい。 レビューで細かく指摘を行い、ChatOpsもやっていくの大切。

• [LT]Vagrantであっぷあっぷした話など

vagrant使えばvirtual boxのアレがなくなるのいいよね

• [LT]やる夫はPerlを学ぶようです

やる夫で学ぶスレの朗読 やる夫のスライドはどうやって作ったんだお？ AA崩れてないし新しかった。 言語処理100本ノックもやっていくのよさそうだ。 Perl入学式次回は行ってみよう。

• [LT]新米エンジニアの育て方

技術愛を持っていない場合は やりたいことのために技術力をつけていこうというのは いいモチベーションの保ち方だと思いました。 業務の問題解決のためにやっていく気持ち。

• [LT] ES2015 の class でアプリケーションを書いてみた話

Javascriptって難しそうな環境ですね。。。

• [LT]レゴでベルトコンベアーを作り、異常検知をやってみた

レゴ工場すごい

• [LT] aruduinoでPCの電源ボタンを押してみる

電子回路の設計のおはなしで、EAGLEで回路設計して 外部にアウトソースして基盤を発注すれば簡単とのことでした。

そうろん

いいカンファレンスでした！楽しかったです！ 今年はYAPCなくて残念でしたが、やぱちーのおかげでよい夏になりました！ 面白かったので来年もやってほしいです！ 今年は懇親会でいろいろお話出来たので、 来年は発表する側になりたいです。 知り合いのエンジニアが0でしたので、 来年があったら知り合いのエンジニアを0からインクリメントさせたい。 エンジニアの友達や知り合いが0問題を解決する必要があると思いました。 今年と来年の目標は外部で発表してアウトプットをしていきたいと思いました。 スタッフのみなさまはお疲れ様でした！

以上。

【報告】YAP(achimon)C::Asia Hachioji 2016midの感想【一日目】

ブログを書くまでがYAP(achimon)Cなのかな？ 05:00まで新宿で飲んでいたけど、頑張って昼前に起きました。 ひっさびさの勉強会(というかカンファレンス)に行ってきてやっていくぞ！ という気持ちが高まったので感想ブログ書きます。 最近ではポエムと言うのでしょうか、 そういうのは気にせず書いていくぞ！

参加したセッション

• MySQL 5.7 + MySQL Fabric + MySQL Routerでぼっこぼこに {する|された} はなし
• AWSのオートスケールとなかよく付き合う
• 「全国タクシー」を支えるクラウドインフラ(AWSとAzureと、時々GCP)
• Fluentdが新Plugin API実装においていかに自由すぎる旧APIとの互換性を確保したかの話
• Browser Extension開発四方山話
• HashiCorp VaultでMySQLアカウントを管理しよう
• [LT]DMM英会話はいいぞ by hiragram
• [LT]エンジニアやエンジニアを目指している人が見るべきアニメ by すてにゃん
• [LT] ESLintを使ってES2015の記法を覚える by sota1235
• [LT応募] PHPのライブラリをcomposer経由で公開した話 by にゃー (mirai_iro)
• [LT]そんなスクラムなら止めちまえ by i47_rozary
• [LT] おまえらのBBQは間違っている by Daisuke Maki (lestrrat)

セッションの感想

• MySQL 5.7 + MySQL Fabric + MySQL Routerでぼっこぼこに {する|された} はなし

MySQL5.7のおはなし mysqlfailoverはread_onlyをいじられない劣化MHAときき、MHA使っていこって思いました。 MySQL Fabricで死ぬまで使い続けて検証してて凄いなと思いました。 地雷原を踏み抜くモチベーションはどこから湧いてくるのだろうか、 なんて思っていたら「技術は勝手には枯れないから誰かが枯らしにいかないといけない」 と言っていたのでなるほどと思った。 枯れた技術は勝手に枯れてないで、誰かが除草剤撒いて枯らしているらしい。 slackにMySQL Casualがあるらしい。今ってslackで技術の話がされているのか。 MLは古いのかしら。プロダクトのチャンネルに入って技術追っていきたい。 知らなかったから乗り遅れてる感じがして焦る。

• AWSのオートスケールとなかよく付き合う

fujiwaraさんてカヤックの人だったんですね。ヒカリエの人と勘違いしていた。 弊社はオートスケール使ってるのかな。手動で増設している認識だぞ。。 アクセスの増減に合わせてインスタンスをたてるの便利っぽいし、お金の節約になるらしい。 ただwebサーバをいくら増やしても、 RDSがボトルネックになればEC2をいくら増やせても、負荷の増大が早過ぎると間に合わないとのこと。 CMがあるから、事前にアクセスが増えることがわかるなら、予め台数を増やせばok。 障害が発生したインスタンスは自動で削除してくれる。そして、代わりの新しいインスタンスを自動で起動してくれる。 つまり設定された台数を保とうとしれくれるもの。 インスタンス削除はterminateになるので、くっついてるEBSも削除されてしまう。 これってログとかも消えてしまうから、S3とかへfluentd使ってログを飛ばす必要があるんだね。 小規模ならオートスケールあってもなくても、金額的に特にかわらないらしいので、 個人とかなら使わなそうだなあ。 オートスケールを考慮していないシステムにあとから導入するといろいろ大変らしい。 minはこの台数を最低限維持しようとするなので、一時的にminの台数を下回ることがある。 desired(希望台数)この台数を維持しようとする。スケーリングポリシーのアクセスにあわせた台数にしてくれる。 OSは起動するけどヘルスチェックが通らないと課金地獄になる。 maxはこの台数以上は起動しない。低めに設定するとスケールできないことがある。 スケーリングポリシーはCloudWatchのメトリクスを元にしたアラームをトリガにする。 spotかdemandか。spotは入札価格をスポット価格が上回るとインスタンス削除されることある。 動作中のスポット価格(需要と供給の価格)できまる。安い時は安いが使いドコロが難しい。 起動したインスタンスがpullさせる。AMIを毎回作る。起動するだけでOKだけど、 設定変更やアプリ修正で毎回AMIを作りなおさないといけない。 デプロイ頻度が多くないサービスなら可能。 S3などにアーカイブを保存、各インスタンスで取得、展開する。AWS CodeDeploy,mamiyaなどを使う。 もしくはrsyncなどでプル型デプロイの自作はbuild途中の状態が取得されないように気をつけよう。 Gitから取得してデプロイは小規模でやっていくならよいが、リポジトリツールなので正しい使い方ではない。 あるホストから全台に○○(ssh)という発想をやめる。 監視で必要なこと動的に監視対象を増減できるツールを使う。mackerekやzabbixを使い、 一台一台みるより、オートスケーリンググループ全台を集約したメトリクスをみる。 一台落ちたぐらいでくよくよしない。監視停止にに失敗することもある。 個別のインスタンスにこだわりすぎない。プロセスみたいなもの。 インスタンスに永続物を残さない。ディスクでなくメモリみたいなものと考える。 この発想てないんだよね。一台一台落ちないようにしている。。。 でもこの考えはSRE的にはどうなるのかなあ。 CPU使用率は40~50%ぐらいで起動するのがよい。100%が50%の二倍の処理ではない。 サーバの性能処理をフルに使わせるのも重要なのかなと思っていましたが、 分散処理が大事。 減らすときは直近1時間の最高が25%になったら。増やすときは大胆に、減らすときはすぐ減らさないのがキモ。 HTTPでアプリが応答したらOKにするヘルスチェックがよい。 EC2で、最新では大丈夫だけど、過去に使用されたことがあるIPアドレスが再割当てされたインスタンスがRedisにつながらないことがあったらしい。 こういうことに気づけるためにもアプリケーションレベルのヘルスチェックをしとくとよい。 ヘルスチェックが通らないとインスタンスが落ちるから。

• 「全国タクシー」を支えるクラウドインフラ(AWSとAzureと、時々GCP)

発表している方がモダンな環境でないとか言ってたけど、 サーバの構成とかみるとそんなことなくてモダンにやっていると思いました。 会社的に物理サーバとかで管理してそ〜とか思ったので意外でした。 AWSはわかるけど、なんでAzureも使っているのかなあ。 Azureをなんで使うのかききたかったなあ。 辞めていくことも決めてないのかしら。

• Fluentdが新Plugin API実装においていかに自由すぎる旧APIとの互換性を確保したかの話

fluentdやっていきたい。 新しいverが発表するときに、古いverで動いているpluginをいじらないでも 使えるようにすることの大変さが伝わってきたし、 ユーザが離れないようにするために大事なことなんだなあと思いました。 新しいverをみんな使っていこう。

• Browser Extension開発四方山話

extension友達っていいな。 vivaldiとかの拡張とか作っていきたいと思いました。

• HashiCorp VaultでMySQLアカウントを管理しよう

HashiCorp Vaultは機密情報を管理してくれるものらしい。 アカウント管理がめんどくさそうな運用だなあと思ったけど、 お客さんの情報を取り扱っているECサイトの会社の人らしいので 上場企業だから厳しいんだろうなあと思いました。 上場するとコンプライアンスが厳しくなるので仕方ないんだと思います。

• [LT]DMM英会話はいいぞ by hiragram

DMM英会話やっていくぞって気持ちになった。

• [LT]エンジニアやエンジニアを目指している人が見るべきアニメ by すてにゃん

さすらいのお勉強野郎ｗ BPS最高ですよね〜 slackのクライアントをいじって上司のアイコンと発言をアニメヒロインにするの いいソリューションw 実装していくぞ！

• [LT] ESLintを使ってES2015の記法を覚える by sota1235

ESLintで叱られてやっていく JSとかよくわからないな〜

• [LT応募] PHPのライブラリをcomposer経由で公開した話 by にゃー (mirai_iro)

たのしくやっていく 発表するの大事だと思いました。

• [LT]そんなスクラムなら止めちまえ by i47_rozary

オレオレスクラムを使って失敗しているよくある話。 スクラムマスターが聴いたら、その使い方じゃダメって言われるやつでは。 スクラムをカスタマイズで使って、オリジナルの使われ方しないけど スクラムはダメだって言われる可哀想な子。 PMは唯一解がないので、適当なものを使ってやっていこう。

• [LT] おまえらのBBQは間違っている by Daisuke Maki (lestrrat)

僕たちは今まで紙を食べていたんだ ヒントは3cm以上

まとめ

懇親会とか初めてだったので、何を話せばいいかもわからないし、 知り合いが０なので緊張して店の前で何分も待ち意を決して入店した。 隣の席がfujiwaraさんで早速ビビった。 でも質問したら優しく答えてくれた。 上場したら待遇とか変わりましたか？とか 子育てってどうですかとか、 ISUCONでなんでそんな強いんですかとか質問したら答えてくれた。 優しい大人だ。尊敬。 スキルセットは業務のために揃えていくもので、コンテストで勝つために揃えるものじゃないよ って言われて、色々ともやもやしていたキャリアとかモチベーションがなんか解決した感じがしました。 モチベーションが全回復したのでやっていきたい。 あと勉強会で発表していくのが言いって言われたのでやっていきたい。 あと酔ったkoemuさんにやっていかないと明日死ぬぞって言われたのでやっていくぞ！ 勉強会でも発表しろと圧をかけられたからやっていくぞ！ すてにゃんさんとアニメの話したかったな。 あとごまさんには結婚おめでとうございますをいい忘れた。 ペパボのAndroidエンジニアの人は名前聞き忘れたのが残念。 エンジニアの友達というか知り合いが0なので辛い。 発表していかないと知られないし、発表していこう。 コミュ力も鍛えていこう。 外の人と会うのは最高なのでもっと勉強会とかカンファレンスに行こう！ ２日目もやっていくぞ！

以上。

CentOS6.7の設定

前回インストールしたCentOS6.7の設定を行っていきます。

SELinuxの無効化

何はともかく無効化しましょう。以下に設定変更します。

SELINUX=disabled

# [cp -a /etc/sysconfig/selinux{,.bak}
# vi /etc/sysconfig/selinux
# shutdown -r now

SELinuxが無効化された事を確認します

# getenforce
Disabled

開発ツール、Baseパッケージのインストール

# yum groupinstall base
# yum groupinstall development tools

監視ユーザ追加

# useradd hogehoge
# passwd hogehoge
ユーザー hogehoge のパスワードを変更。
新しいパスワード:
新しいパスワードを再入力してください:
passwd: 全ての認証トークンが正しく更新できました。

作成したユーザに管理者権限付与

/etc/sudoersに以下の内容を記載

hogehoge ALL=(ALL) ALL

# cp -a /etc/sudoers{,.bak}
# visudo
# cat /etc/sudoers |grep hogehoge
hogehoge    ALL=(ALL)   ALL
$ sudo whoami
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.
[sudo] password for hogehoge: 
root

root権限が付与された事を確認。

rootユーザリモートログイン不可設定

rootでssh接続は禁止して、作成したユーザでssh接続するようにしましょう。

/etc/ssh/sshd_configに以下の内容を追記

PermitRootLogin no

# cp -a /etc/ssh/sshd_config{,.bak}
# vi /etc/ssh/sshd_config
# service sshd restart
# service sshd restart
sshd を停止中:                                             [  OK  ]
sshd を起動中:                                             [  OK  ]
# cat /etc/ssh/sshd_config | grep PermitRootLogin
#PermitRootLogin yes
PermitRootLogin no

PermitRootLogin noが追加されていることを確認。サービスも正常に起動しています。

リモートログインの確認

rootユーザでのログイン不可の確認します。

# ssh root@xxx.xxx.xxx.xxx
The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx.xxx.xxx.xxx' (RSA) to the list of known hosts.
root@xxx.xxx.xxx.xxx's password: 
Permission denied, please try again.

Permission deniedで権限が拒否された事を確認

一般ユーザでのログイン確認

# ssh hogehoge@xxx.xxx.xxx.xxx
hogehoge@xxx.xxx.xxx.xxx's password
$ 

一般ユーザが管理者権限になることを確認

$ sudo su -
[sudo] password for hogehoge: 
# 

プロンプトが管理者権限になったので管理者権限になることに成功

プロンプトが一般ユーザになったのでログイン成功

Quizここで#や$になったりしているのはなぜでしょうか。調べてコメント欄に書いてみてください。

カーネルパニック設定

「/etc/sysctl.conf」はカーネルパラメータを記述する設定ファイルです。 ここにパニックリブートの設定を追加

# cp -a /etc/sysctl.conf{,.bak} 
# echo >> /etc/sysctl.conf 
# echo kernel.panic = 30 >> /etc/sysctl.conf
# cat /etc/sysctl.conf |grep kernel.panic
kernel.panic = 30  //パニック後30秒後に再起動

yum設定

参考サイト : Yumの構成 : yumが遅い場合にダウンロードを速くするyum-fastestmirror : CentOSでyumのリポジトリを国内指定したりほか

1.yumのプラグインをインストールしてダウンロードの速いミラーサイトを自動で選択するように設定

yum -y install yum-fastestmirror

2.「mirrorlist=」の末尾に「&cc=JP」を追記し、国コード別のミラーリストを返すように設定

# cp -a /etc/yum.repos.d/CentOS-Base.repo{,.bak} 
# vi /etc/yum.repos.d/CentOS-Base.repo
# cat /etc/yum.repos.d/CentOS-Base.repo |grep mirrorlist=
# If the mirrorlist= does not work for you, as a fall back you can try the 
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib&infra=$infra&cc=JP

3.「yum -y update」ですべてのパッケージを、それらが依存するパッケージとともに更新

# yum -y update

4.更新がないことを確認

# yum check-update
読み込んだプラグイン:fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: ftp.tsukuba.wide.ad.jp
 * extras: ftp.tsukuba.wide.ad.jp
 * updates: ftp.tsukuba.wide.ad.jp

5.yumおよび関連ユーティリティの設定ファイルである「/etc/yum.conf」でpluginsが1に設定されていて、yumの機能を拡張するプラグインが有効である事を確認

# cat /etc/yum.conf |grep plugins=1
plugins=1

6.mirrorlistの設定が正しくされているか確認

# cat /etc/yum.repos.d/CentOS-Base.repo | grep mirrorlist=http://
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus&infra=$infra&cc=JP
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib&infra=$infra&cc=JP

自動起動設定

1.以下のサービスを自動起しない用設定

# chkconfig --level 2345 mdmonitor off
# chkconfig --level 2345 atd off
# chkconfig --level 2345 smartd off
# chkconfig --level 2345 haldaemon off
# chkconfig --level 2345 restorecond off

サービス名	サービス内容
mdmonitor	ソフトウェアRAIDをモニターするサービスなのでソフトウェアRAIDを使用していないので無効
atd	単発的にスケジュール化した コマンド を実行させるデーモン。指定時間にコマンド実行を行える，atコマンドを使用したい場合に利用
smartd	ハードディスクの内蔵の自己診断機能(S.M.A.R.T.)を利用し、異常が発生したときにレポートするデーモン。RAIDを使わないので無効
haldaemon	システム上のハードウェアに関していくつかのソースから情報を集めたり管理したりするデーモン。デスクトップ環境ではないので無効
restorecond	SELinuxと連動して、ファイルの作成などを監視して適当なラベルを付与するがSELinuxは無効なので、こちらも無効化

参考サイト : 不要なサービスは停止～ソフトウェアRAIDモニター（mdmonitor） : 不要なサービスは停止～HALデーモン（haldaemon) : 不要なデーモンを停止させる (CentOS 6.5) : 不要なデーモンを停止しましょう

2.設定変更したlevel設定の確認

# chkconfig --list |sort -s

offにしたサービスが起動していないことを確認

CentOS6.7のインストール

CentOS6.7をインストールしたのでメモ代わりに手順を共有します。

• CentOSのisoダウンロードやvirtualbox環境は省略します。

参考サイト : CentOS6.4をISOを書き込んだDVDからインストール

1.「Wellcome to CentOS 6.7!」のメッセージ画面

「Install or upgrade an existing system」を選択

2.「Disk Found」の画面

「Skip」を選択しCDチェックを行わない

3.「Cent OS6」の画面

「Next」を選択

4.言語の選択

「Japanese(日本語)」を選択し、「Next」を選択し次の設定へ

5.キーボードの設定画面

「日本語」を選択し「次(N)」で次の設定へ進む

6.「どちらのタイプのストレージデバイスにインストールしますか？」

「基本ストレージデバイス」のラジオボタンを選択し。「次(N)」を選択

7.「現在お使いのシステム上には既存のシステムがインストールされています。どのようになさいますか？」

「新規インストール」のラジオボタンを選択し「次(N)」を選択

8.ホスト名

「localhost」に設定

9.ネットワークの設定

「ネットワークの設定」を選択 「System eth0」を編集

「自動接続する(A)」にチェックする

※ローカルIPアドレスを割り当てたい場合は以下の設定も行いましょう。 方式を「DHCP」から「手動」に変更 「IPv6のセッティング」タブに移動し、無効化されていることを確認 「適用」を選択し設定を反映させる。 「ネットワーク接続」のウィンドウを「閉じる」で閉じ、「次(N)」を選択

「次(N)」を選択

10.タイムゾーンの選択

「アジア/東京」で変更なし Rootパスワードを設定

8文字のものを設定

11.どのタイプをインストールをしますか？

物理ボリュームの場合

中段にあるボックスから「カスタムレイアウトを作成します。」を選択 既存のパーティションを全て削除

「作成」を選択し、以下のパーティションを追加し、「次(N)」を選択

マウントポイント サイズ(MB)	基本パーティションにする	ファイルシステムタイプ
/boot 250	チェック	ext4
<適用外> 2048	チェック	swap
/ 150328 (残り全て)	チェック	ext4

「ストレージ厚生をディスクに書き込む中」というウィンドウが出るので、「変更をディスクに書き込む」を選択

論理ボリュームの場合

カスタムレイアウトを作成するを選択する。 パーティションの設定は以下の通りとする。 「swap」領域を「2048MB」割り当てる。 「/boot」領域を「250MB」割り当てる。またファイルタイムを「ext4」とする。 上記のパーティションの設定完了LVM物理ボリュームを作成する。設定は以下の通りである。 ファイルサイズ:physical volume サイズ:5892MB 最大許容量まで使用:チェックを入れる LVM物理ボリューム作成後、次にLVMボリュームグループを作成する。設定は以下の通りである。 ボリュームグループ名:VoGroup00 物理エクステント:4MB マウントポイント: / ファイルシステムタイプ:ext4 論理ボリューム:LogVol00 サイズ:5892MB

12.ブートローダの設定

デフォルト設定で「次(N)」を選択

CentOSのインストール完了

【報告】YAPC::Asiaの感想【8/21&8/22】

【Blogを書くまでがYAPC】

去年と数えて今回が二回目のYAPCでした。このblogもYAPCの感想を書く為、専用となってしまっています。

昨日は以下のショックでblogを書く元気が無くなってしまいました。

YAPCパーカーのサイズ感を完全に誤って早速秋用のパジャマに成り下がった。XL異常なデカさ。

— トトス (@oza_shu) 2015, 8月 21

しかし、今回でYAPC最後ということなので、気を取り直してblogを書かないわけにはいけません。それでは8/21&8/22の感想を書いていこうと思います。

・8/21

【参加したセッション】

メリークリスマス！

世界展開する大規模ウェブサービスのデプロイを支える技術

TBD

Conway's Law of Distributed Work

Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN

Lightning Talks Day 1

【セッションの感想】

・メリークリスマス！

まずはPerlの父Larry Wallのメリークリスマス！から。「メリークリスマス！」って何のこっちゃと思ったら、ついに噂のPerl6が今年のクリスマスにリリースされるとのことが発表されました！( ※ただし約束はしていない。)

そしてLarryのPerlとトールキンの作品との関係性。Perl5である「ホビットの冒険」からPerl6である「指輪物語」は書かれるまで、何年も待たなければいけなかった。そして、それはホビット(Perl)が成長していく物語なんだ。と知性あふれるLarryの語りと、それを同時通訳をこなせているプロの凄さからニヤニヤが止まりませんでした。観ててよかった「ロード・オブ・ザ・リング」。物語性あるプログラミング言語はなんて素敵なんだ。「PerlはUnixのtoolになり見えない存在になることで革命的になった。 」このUnixと共に成長していった感じも好き。革命的なものは革命的とみないものなんだ。あとは「人間の価値は何を得られるかでなく何を与えられるか」というgiveの精神。これがOSSの精神なんだろうなあ。「I fail good」正しく失敗できるようになりたいです。

最初がLarryWallのセッションだったからか、Larryより同時通訳者の方が話題になり、誰も質問しないなんて展開になってしまったのかな。とLarryには申し訳ない気持ちにはなった。

・世界展開する大規模ウェブサービスのデプロイを支える技術

consul とstrecherめっちゃ早いって話だった気がします。
成果物をプルリクするよりS3に管理することで早いとのこと。デプロイ話はピンと来なかったなあ。cap2&gitより早くて、autoscaleと連携しマルチリージョンできるらしい。ココらへんは用語も知らないこと多かったので、ググッて調べとこ。Jenkins先生のテストは大事っぽい。YAMLは何の文脈で出てきたっけなあ。

 
##ブレイクタイム##

お弁当の支給ありがとうございました。美味しかったです！

・TBD
お昼のお弁当をさっさと食べ、Matsのセッションだったから一番前ので席を確保。
おじさんが座ってたから2つぐらい席を離して座りました。するとスタッフの方が話しかけててMatsだった。

隣にMats様が座っていた #yapcais

— トトス (@oza_shu) 2015, 8月 21

今日からRubyやるわ。

— トトス (@oza_shu) 2015, 8月 21

※ Ruby始めます。

「今日はRubyの話は封印します。」では何の話をするか、「不揮発性のメインメモ」の話をします。でも実際スライド作ったら15分しか持たないから不揮発性のメインメモリがもしもできたら、言語設計者としてどのような言語を設計するかっていう話は飲み会とかで」と追っしゃてました。いつか聞きたいです。笑

それでは「Rubyの封印を早速解きます。Rubyの悪口を言っても問題ないのは問題ないから」と初めてMatsをみたけど面白い方だった。

Rubyの設計はPerlやLispの影響を受けているから、もしいまRubyを設計をしたら取り入れなかった機能の話をしてくれた。こういう話を聞くと、プログラミング言語の説明で、OOの言語の影響を受けているって話はこういうことだったんだと納得出来ました。新しくプログラミング言語を作った言語設計者も意識したプログラミング言語があるんだ。そして今新しく作っているプログラミング言語のデモをしてくれた。シェルスクリプトが今見直されている。その理由がパイプ処理でCPUのマルチコアを正しく使うから、っていう話は面白かった。ハードウェアの進化に伴い、プログラミング言語の使われ方も変わるのだろう。それを踏まえた新しいプログラミング言語「Streem」については今後チェックしておこう。

・Conway's Law of Distributed Work
Remote! リモートワークの話でした。今はインフラエンジニアをやっているので、このリモートワークとは縁が無いだろうけど、諦めない。

【Effective communication saves Time】

リモートワークでのコミュニケーションの話で、次のようにグループ分けをしていた。「Text Chat:Archive,Group Chat, Privete Chat. Full Participation」

【コミュニケーションを円滑にするツール】
・CHATOPS:lita,hubot
・Audio/Video Communication:Headphones,Microphone,Camera
・HipChat,Google Hangouts,appear.in,sqwiggleSCREEN SHARING:Screenhero(for 　　　slack),Hip Chat,join.me.WebEX
・CODE REVIEW:Pull Requests,Gerrit.ReviewBoard.Code COllaborator
・Piivotal Tracker,Trello,Github Issues,waffle.io for GitHub Issues
・Ether[ad,Haclpad,Google Docs.Github Wiki
・Dropbox,Boc.net,GoogleDrive.NFS
・Google Calendar,Exchange
※誤字脱字あるので後でスライド再度確認しておこう。

【Everyone should experience remotie work】
リモートワークを理解してもらうには「期間は一週間で実感してもらうのが大事」

【Have on-site meetups】
定期的に人と会うのが大切。invite remote workers into hallway conversations. Over communicate. 37signalsのREMOTEでも似たような話があったような。読み返してみよう。

【アイデアを書き、コミュニケーションを行う】
これは付箋なり、テキストチャットなり、人それぞれの好み。Share your personality.人格個性を共有。自分の趣味は何か、オフィスを離れて何をしているのか。オフトピックの場を設ける。つまりはHipChatの雑談板みたいなものですね。Remoteって能力だけで評価するのかなと思ったら、人格であるソフトパワーも大事なんだ。結局人と人だから当然か。

【Exhibit a "visible pulse.】
大事なのはバイタルを見せる。生きてることを知らせる。いついるのかいないのか知らせる。 なんかネトゲの話に通じるのではないかと思いました。
Pick a timezone.Standard Operating Time(SOT).基準の時間を設ける。これはきっと本社がどこなのかで決まるんだと思う。
sociotechnical Theoryは造語らしい。

【感想】
このセッションで思ったのはRemoteWorkはMMOと近い何かがあるし、同時通訳者がいるなら英語で質問をするのは避けるべきだと思いました。日本語で質問したほうがいい答えが返ってくるのは良い知見だ。「日本語で質問してね」と言ったのはスピーカーなのか通訳者の心の声が漏れたのかどっちなんだろう。
でも英語出来る人が多くて驚いたし、凄いと思う。懇親会とかでせっかく来てくれた外国人スピーカーと話したら嬉しいな。そしてそういうことができるようになりたい。

※英語始めます。

最後に質問の答で「常にスマートフォンを握っていると友達や家族が強いフラストレーションを持つよね」これってリモートワーク関係なく大切なことではないでしょうか。

・Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN

Podcastの話でした。あとお金の話。

.fmってドメイン名らしく年間1万以上するらしい。Podcastも大変そう。音質という宗教の世界になるっていうのはこだわりだしたら怖い。静かな場所であればiphoneのスピーカーでも大丈夫らしいし、大事なのはいかに雑音が入らないところでやるのかなんだろう。とりあえず溜まってたrebuild.fm聴いていこう。
「大規模でも小中規模サービスでも捗る microservices な Web サービスのつくりかた」を見たくて途中で抜けてしまったけど、結局、満室で部屋にはいることができず、その後は無限コーヒーを飲んでました。スライドを後で確認しておこう。

・Lightning Talks Day 1 

みんな話が面白く楽しかったです！papixさんのは笑ったし、嫁botと一緒にプロビジョニングする話もあらゆる意味ですごかった。

・8/22

【参加したセッション】

ISUCONの勝ち方

サーバーサイドエンジニア(特にPerl)のためのiOSアプリ開発入門

Adventures in Refactoring

Posture for Engineers 

Run containerized workloads with Lattice 

Profiling & Optimizing in Go

Lightning Talks Day 2 

クロージング

 

【セッションの感想】

・ISUCONの勝ち方

おはよー。YAPC寝坊した。ううう

— トトス (@oza_shu) 2015, 8月 22

走って走ってちょっと歩いて走ったらギリギリ間に合った！

チューニングってどんなことをやるのか興味がありました。

ISUCONとはベンチマークツールの計測したスコアで順位付けするらしい。
勝つためには、普段から一緒に作業をしている人と作業分担をして、お互いの作業をチェックしてミスを減らすことが大事だと。問題をいち早く相談して解決すること。決まったことはメモをして書き出し、後戻りは減らす。最初の1時間は課題の理解、プロファイリングとチューニングの方向性。最後の30分再起動テストを設けること。ちゃんと起動するか確認が大事。

【事前準備】

PrivateGitRepository,Wiki,メンバーのssh公開鍵、秘伝のタレ、Chatroom,技術選択についての簡単な打ち合わせ、過去問を解く、ローカルより、EC2,GCPとかで試したほうがいい。

【チューニングの進め方】

１：課題の理解、レギューレーションヤ当日の説明を理解、どのようにスコアが決まるか、失格になるのか、ブラウザで課題となるサイトへアクセス。とりあえずベンチマークを動かす。

初期設定が間違いなど、はずれインスタンスをひいたかわかるため、とりあえずベンチマークを動かす。

2.プロファイリング、Webアプリで起きてることを知る、アクセスログの解析、MySQLのSlowLog解析、アプリケーションの解析、負荷分散。

【アクセスログの解析】

ベンチマークツールがアクセスしている先を確認。頻度とレスポンス時間をバランスよく見る。スコアに関係ないところはもういじらなくていいよねと決める。analyze_apache+log,kataribe

apacheのアクセスと具解析、httod.confをいじり、accesss_logを消し、サーバ再起動し、解析にかける。kataribeは１回しかアクセスしてないなら重くても無視する。全部を見てどこをチューニングするか決める。

【MySQL_SlowLog解析】

クエリ実行回数と頻度の両方を見る。遅いクエリ、より秒間数千クエリを食うクエリ両方を見る。ツール。pt- query.MySQLSlowLOg解析。myconfを0にして全てをslowlogに出す。最後にはslowllogを消す。どんなクエリが動いてるのか確認。

【アプリケーションのプロファイリング】

各言語のツールを使う。strace,tcpdumpなど。
アプリケーションが何をしてて、どこと通信をしているのかを確認することが大事。
サーバの負荷を見る、top.iftop,iotop,dstatなどなど、ネットワークがつまるなど、通信が一番重くなる。

【サーバ構成】

Client,リバプロ、APPサーバ、Cache,KVS,RDMSそれぞれどんなサーバで、ミドルか、その設定、過去には設定のtypoや罠もある。
チューニングの方向性を決める。与えられたサーバを使い切る。

【効率の良いCPUの使い方を知る】

コンテキストスイッチング。いかに何もしないアプリケーションにいかに近づけるか、参照通信を減らし、無くしていくこと。
Apache VS NginxだったのがNginx VS h2oになると予想。

h2oっていうのは知らなかったな。h2oはスレッドなのでNginxより早いが、設定はNginxのほうがある。外部プロセスの起動HTMLテンプレート処理、テキスト画像変換処理、RDMBMS/Cacheとの接続、N+1問題などが重い処理。

 

【RDBMS/SQL】

B+Tree。一番下にデータがぶら下がっている。インデックスはidだけがぶら下がっている。つまりプライマリキーがぶら下がって いる。このしょりが重い。MySQ:LのOFFSET処理。最後の古いページも見る。捨てるデータの読み都営を最小限に。

どうやってデータを取りに行くかを心に描くのはちゃんと動きを理解しないといけない。これは小手先のスキルじゃなく大規模システムの会社で働くなどして、スキルを磨かないとダメだ。やっぱり大きなシステム持ってる独自サービスの会社に勤めてみたいなー！

最後に初期状態を記録。変更を都度記録。前日はよく寝る。あきらめないことが大事。

 

・サーバーサイドエンジニア(特にPerl)のためのiOSアプリ開発入門

swift2.0で仕様が固まり、もうobjective-Cを書くことはないだろうと聞いて、これはiOSアプリも触ってみたいなと思いました。APIを使ったデモはネットワークの問題で上手く行かなかったけど、xcode-betaでのスライド遷移の簡単さを見るとGUIでもできることあるみたい。でもswiftはマシンパワーを要求するからMacbookProと外部ディスプレイを買ったほうがいいというのは知見だ。あとiOSアプリのいいところは作ったのを手軽に他の人に見てもらえるから、フィードバックもらえてたのしい。自分しか使わないモノを作って、自分が知りたいことだけを勉強していくのがいいよっていうのはMuraseさんでもそうなんだと思い親近感。

・Adventures in Refactoring

個人的には一番面白かった話！ヒゲで雑音が入って通訳の人からマイクの位置変えるようにとお達しが笑

リファクトリングとはコードを変えるが、振る舞いは同じ。悪いリファクター結果を計ることが大事。一貫性もいいと思うが、一貫性というものは計れないものだ。重要なのは正しいことをキープすること。良いリファクタリングは取り除くこと。不要な行を取り除く。テストカバレッジが改善されるとよい。テストのExpressabilityを改善するとよい。テストの表現性。これは造語らしい。

テストの振る舞いが変わっているところに対してリファクタリングを行う。パフォーマンスの改善がされること。コードの振る舞いを変えないで、スピードを改善。その結果を測るものとしてディベロッパーがハッピーがどうかはコードを見れば測ることができるwリファクタリングとISUCONの勝ち方も似ていると思った。

 【リファクタリングの理由】

ディベロッパーがハッピーになり、性能向上する。将来の作業のに向けてのの自信を得ること。そして技術的負債を払うこと。リファクタリングした後は自信を持てる。そして他のディベロッパーの教育になる。システムがどういう振る舞いをしていくか学ぶことができる。

【テクニック】

コードの中にちょこちょこハッピーを得る。それは測定できる。例えば二つのコードを一つにするとか、アドレスをオブジェクト、リストにするとか、クオートマークの一貫性や、抽象コードを入れること。関数を入れること。小さなテーブルをスプレッドシートなどでハッシュにする。

【大切なこと】

スタイルガイドがあることが大事。それを得ること。まずスタイルガイドを決める、後はルールを踏襲する。$go fmt とか素晴らしい。というよりgo素晴らしいだってw

verbe type.動詞を名詞化できるかどうか。ちいさなメソッドを名刺にする。抽象化レイヤーを導入する。pullリクエストをマージできるのか。

あと 不要な抽象化レイヤーを取り除く。

【リファクタリングの落とし穴】

既存のバグ。リファクタリングをやっている時にバグを直してはダメ。壊れた時、fixが原因なのか、リファクタリングが原因かわからなくなるかた、それぞれ別に直していく。これは最後に質問で補足されていました。

パフォーマンスの変化がわかる。コンテキストなど。

【リファクタリングを分解】

Deprecate; 古いメソッドを取れ除けない時にする。これはtail_bytesの時はできない。Backwards Compatible : currentが一つから二つになるとき、APIを書き換え全てcurrentとする。

ここはデモで話してたところなので再度確認したい。

また大きなリファクタリングにはリスクがある。リスクを抑制するにはToolsを書く。大規模なリファクタリングにはコードが増える。

【大規模なリファクタリングによいツールの紹介】

・Backscatter.なんでコールされているのか吐く。コールスタックより上流のスタックがわかる。良い点はランタイムで実行される.

・Science:rubyのライブラリ。実験ができる。古いと新しいメソッド二つを実行できる。e.use/e.newパフォーマンステストでもscience.グラフが出る。rubygemsでパブリックされている。scienceを後でダウンロードしてみよう！

【リファクタリングの不満話】

Backscatterは時間がかかるし、scienceはrubyしかない。可視化できなくてエディタレベルしかない。それに比べてjavaは素晴らしい。言語の中に入っている。Deprecatedがある。C++14も入ってる。Djangoなどのフレームワークもある。

【Q&A】

リファクタリングのアプローチに意見が分かれたらPull requestを使う。style guideがあることが大事。セミコロンやクォーテーションはどっちがいいか等はstyle guideを見て決めていく。リファクタリングのアプローチはテストの結果をコミュニケーションのキーにしていく。テストの結果がいいほうを取ればいいんだね。

リファクタリングと開発どっちを優先するか。その基準は変更に関する自信のレベル。変更する前に自信がないとダメ。その自信を計測するのは難しい。機能の動きに変化がないか自信が大事。ここはテストを通して、決めていけばいいのかな。

先ほど話にあった、バグfixとリファクタリングの優先の問題は、個別に切り分けてやるのが大事。

リファクタリングの目標は振る舞いを変えないこと。それはテストを行うこと。テストカバレッジと表現性。テストがどれだけ複雑であるか。テストの複雑性はコード改善されないとダメ。テストカバレッジはテストがうまくいっているかでわかる。

リファクタリングのデザイン主導は好ましくない。コードがテストに、良いテストからコードは生まれる。テスト駆動ドリブンのことなんだろう。最初にテストがあって、それに通るコードを書くことが大事。コードを最初に書いて、それが通ってしまうテストを書くことになるのは避けるべき。

スタイルガイドを変更するかはpull requestで管理する。「”」にするか「’」にするかは、pull requestでレポジトリで管理する。リファクタリングが終わったらスタイルガイドを変えるなど、別々の問題としている。リファクタリング途中で変えたりはしないのかな。

レガシコードに対してのリファクタリングはどうするか。まずはテストを書くとこから始める。テストを書き切ってから、リファクタリングをする。別々に切り分ける。変更を行う前に6か8つのテストを加えるのは最初のプルリクでする。

テストのリファクタリングは絶対にやらないといけない。テストを変更するのは別のリファクタリングにする。コードとテストのリファクタリングはミックスして時にはやる。ケースバイケースなのかな。

リファクタリングとISUCONの勝ち方の類似点は振る舞いを変えず、パフォーマンスを向上させること。それがいかに大変なのか。奥が深い。

・Posture for Engineers 

エンジニアのための姿勢の話。

エンジニアでありヨガのインストラクターの方の話だった。正しい姿勢の仕方と前傾姿勢の悪影響を話してくれた。腹痛も姿勢の問題かもしれないんだって。

座ることは新しいこと。長時間座ることができない。長い時間座っていると体が正しく機能しない。筋肉は縮んだり、弱くなったり、腰痛が出てくる。脊椎がずれてくる。カイロプラクティックでは背骨が全ての中心とする。咳つがずれると神経が圧迫する。

腹痛の原因が原因だったりする。ストレッチ大事。姿勢を保つ筋肉を鍛えることができる。みんなの体は違うからできないポーズがあってもへこまないで。痛みを感じたらやめてた方がいい。痛みがあるのは不自然なことだから。

立って仕事をするのはいいけど、今まで座ってた人がやると、膝を痛めたりするかも。立方として耳が背骨の中心に来るようにして前傾姿勢を防ぐ。

みんなで実際に立って面白かったなｗ

【ストレッチ方法】

床の上に座る。肩甲骨を壁につけて、４秒かけて頭を前後に倒す。脇の下の筋肉は四つん這いcat/cow、または椅子に座って肩を中心にし、頭を倒す。

 骨盤が丸々と膝にも問題が出る。腹筋を鍛える。丸まらないようにする。でも腹筋運動は危険かもしれないから、エクサザイズボールに座るのが良い。30分座ることから始めよう。

以下はポーズの名前。後でググっておこう。

BoatPose/full pose.背骨をまっすぐにするのがポイント。

Staropen/Close。

Standingholdpose/Ardha

Uttanasana(Halfway Lift)

座りっぱなしは体に良くないけど、そういう仕事だから気をつけた方がいい。

姿勢について知見を得ることができ感動した。

・Run containerized workloads with Lattice 

 CloudFoundryオープンソース、もっと簡単なLatticeっていうのを作ったよって話。

Latticeのアーキテクチャーを話してくれた。LatticeはDockerやBuildPackを実行できる。CloudFoundyより簡単なのが特徴。適していないのはプロダクション環境ではダメ。Persistent dataもダメ。セキュリティーポリシーが強いのもダメ。使うのはローカルでお願い。

Kubernetesはスケジューラにすぎない。SelfHealing,LoadBalancingは他でやらせること。

Latticeはインストールが楽で、vagrant upだけでいい。クラスター化できるしterraformも適している。スケジューラの名前はDiego。Task,LongRunningProsess。Schedulingはコンテナの数 インスタンスの数。

【Usage】

Dockerイメージのデプロイや、アプリのスケールアップとか。Builtpack:dropletをつくったら実行。自分のワークロードも作れる。own workloadのことね。

ルーティングレイヤー：デフォルトあるが、変えることもできる。

【Logs】

アプリログを指定。X-Rayアプリのインスタンスディトリブーションゾーンを可視化。X-RayhはOSSだよ。

Latticeは開発環境で、本番環境はCloudFoundry.でも使い方はほとんど似ていて、コマンドが違うだけ。Latticeでローカルでいじってから始めるのが良さそうだった。インストールも簡単だったし。

・Profiling & Optimizing in Go

Go,Go,Go,Go,Go.

Go言語の話だった。

終始、デモだったのでEmacsの流れるようなデモコーディングにインフラはVimで、開発はEmacsでやろうと思いました。

※Emacs始めます。

go tool pprofはすごい便利そうだった。いろんなツールが有るんだな。

・Lightning Talks Day 2 

 MySQL5.7はデフォルトで360日でパスワード変更求められるらしい！これで呪いは回避できたかな。

みんな昨日今日で作ったとは思えない内容で面白かったです。すごかった！

・クロージング

 これで本当にYAPCは終わりなんだなあと思ったら感慨深いですね。いろんなエンジニアの同窓会にもなってたんだろうなあ。最後の最後で知れてよかったです。こんなにも楽しいカンファレンスって無いんじゃないでしょうか。

Perlはワンライナーいや、プログラミング書かない人でも、十分楽しめるセッションばかりのカンファレンスなんて無いですよ。今はperl以外の言語を書いていて、perlから巣立っていった発表者の方々も多かったのではないでしょうか。
別の言語や、Perlとは全く関係ないサービス、開発手法について話せるカンファレンスなんて他にないですよ！Perlのコミュニティとそこで育った皆さんの懐の深さが知れました。Perl入学式みたいにプログラミング入門の勉強会があるし、Perlコミュニティっていいですよね。Larryも言ってたけど育っている感じがとってもいいコミュニティだと思います。

最後のYAPC今回は2130人参加とのこと、前回は1361人参加だったので、最後にこんなに多くの人が集まったのは凄いと思います。そしてスキルが有ればこんなにも沢山のエンジニアさんと出会えるのって凄いことだと思いました！

そしてスタッフの皆さんお疲れ様でした！楽しかったです！

ありがとうございました！

【報告】YAPC::Asiaの感想【二日目】

【ブログを書くまでがYAPC】

YAPCのブログを書くために開設したので、

もちろん二日目の感想を書かせていただきます。

一日目の興奮とアルコールが抜けきれなかったので、中々寝付けませんでした。

その結果。

#yapcasia 寝坊した！

— oza_shu (@oza_shu) 2014, 8月 30

一番聞きたかった「突然ITインフラを任された人のための…監視設計入門」には

ギリギリ間に合ったので良かったです。

そんな感じでYAPC二日目が始まりました。

二日目きたー。

【参加したセッション】

突然ITインフラを任された人のための…監視設計入門
Perl Mongersのためのstrace入門
Perl入学式 in YAPC::Asia Tokyo 2014
あやかNow!
そんなにビッグでもないデータ処理手法の話
Lightning Talks Day 2
キーノート
YAPC::Asia Tokyo 2014 - クロージング

【セッションの感想】

・突然ITインフラを任された人のための…監視設計入門

→インフラエンジニアとして一番身近でためになると思い楽しみにしていたセッションでした。NOWで現行踏襲という設計で障害が絶賛発生中な現場にいるので、設計とはどうやるのか気になってました。

これは質問しそびれたことが一つあって、オープンソースのミドル使ってるWEB系の会社は障害発生時どのような対処をしているのか気になった。OS,NW,DB,運用MW,業務MW幅広い領域だと思う。SIerはベンダー製品と手厚いサポートがあるけど、WEB系はどうしているのか幅広いスキルと知識を持って対処できるのか、てかどうやったらWEB系のインフラで働けるのか！ハードウェア保守としてはAWSみたいなクラウドの時代が来たら死ぬと思いました。

・Perl Mongersのためのstrace入門

→先頭でstraceの見方の話を聴いていてら、後方から上手く動いてないんじゃないかとか

声が聞こえてきて、セッション中に登壇者に話しかけるのすげえ！誰だろうと思ったら

弾小飼さんでCooool!!と思いました。もちろんstraceはちゃんと動いていて、straceの見方を教えていただき勉強になった。普段はstraceをとってもサポートに投げて終わりと他人任せな事しているので、自分でもちゃんと調査します。反省

時間に追われて発表をしているからラフなセッションというのは中々難しいのかなとも思いましたが、ぶっ込む弾小飼さんCooool!

・Perl入学式 in YAPC::Asia Tokyo 2014

→Perl入学式#1補講以来の参加だったので、かなりパニクりながら練習問題に取り組んだので時間があっという間に過ぎました。サポートの方々に助けられながらもPerlを動かせてプログラミングすごい！たのしい！という感覚を得られました！9/23の第3回は参加しますので、雅なPerlを読んで望みます。最終問題の同じお店が出ないコードが未だに書けていなくて、ブログに載せようとしたのですが間に合わなかった。

そういえば一日目のHUBで話したお姉さんとは別の席だったから、話す機会なく残念です。

・あやかNow!

→Rubyアイドルがいた！かき氷うまい！無限コーヒー！

・そんなにビッグでもないデータ処理手法の話

→何をしたいか。サイズはいくつか。それにあったプラットフォームを選ぼう！という話だったと思います。FrameworkやAPI等の概念がわからず技術的なことは余りわからなかった。取り敢えずわかったことはビッグデータはペタサイズのデータと聞いて、ビッグデータに関わることはなさそうだなあというのは分かった。

#yapcasia ビッグデータはどんな世界で扱っているのか。官公庁でも扱ってない木ガス。

— oza_shu (@oza_shu) 2014, 8月 30

・Lightning Talks Day 2

→よいLTばかりでした。ドラ娘も良い。有名な人達を早速フォロー！きっと技術的なことと変態的なことがTLにいっぱい流れるんだろう楽しみ！

・キーノート

→趣味と仕事の話。3年目になり仕事にも慣れ始めてきて漫然とした態度で仕事をするようになった自分には刺さりました。自分がしたいことを仕事にしたい！エンジニアってめっちゃ楽しい！と思う人が増えると世界がよくなるんだろうなあ。そういう姿勢で仕事もしたいとも思います。100%受託の仕事をしていますが、受託は新しい人と技術に出会えると聴いて、受託なんてと腐らずに得られるものは得ようと思います。20代になにをするかは大事って話は20代後半に突入した自分には何かやらないとって思いをさせてくれました。これからどんなエンジニアになりたいか、勉強していろんな人に出会って、ロールモデルを見付けたいと思います。もっとエンジニアらしく振る舞いたいです。

・YAPC::Asia Tokyo 2014 - クロージング

→来年もあると嬉しいです！技術的にリベンジしたい気持ちでいっぱいです。技術的にも分かることを伸ばして来年はいろんな人と技術的なことを話したいです！エンジニアの人たちってこんなにいるんだと感激しました。

今回は1361人参加とのことで、スキルが有ればこんなにも沢山のエンジニアさんと出会えるのって凄いことだと思いました！懇親会来年はワイワイの中に入れるようにしたい！

そしてスタッフの皆さんお疲れ様でした！楽しかったです！

ありがとうございました！

YAPCのために開設したこのブログも、せっかくだから勉強した技術的なことや勉強会の感想など書いていこうかなあ。

そういえば一つ自慢話、この間の神楽坂ゆかさんのライブ最前列でした！

世界一かわいい人をすごく近くで見れた。( ･ㅂ･)و ̑̑ ｸﾞｯ !