こんにちは！ビジネス開発部の神谷です！
今回は、過去に何度か当ブログで紹介している「IDCFクラウド RDB」についての記事となります。
IDCFクラウド RDB の開発進んでます！ - IDCF テックブログ
IDCFクラウド RDB を少しですが紹介 - IDCF テックブログ

ユーザーの皆様から一番多くリクエストをいただいていたIDCFクラウドのRDBですが、
ついに6月28日にリリースされます！

www.idcf.jp

オールフラッシュ性能・シンプルなUIなど、従来のIDCFクラウドの良い点はそのままに、RDBならではの工夫点も盛りだくさんとなっております。
そんなRDBですが、リリースに先駆けて東京・大阪で活用セミナーを開催いたしました！
IDCFクラウドセミナー ～データベース活用法～（東京編） - IDCフロンティア／IDCFクラウド | Doorkeeper
IDCFクラウドセミナー ～データベース活用法～（大阪編） - IDCフロンティア／IDCFクラウド | Doorkeeper

<プログラム>
・新サービス「IDCFクラウド RDB」のご説明
・「IDCFクラウド RDB」の技術説明
・「IDCFクラウド RDB」のデモンストレーション
・質疑応答
・懇親会

ここからは、セミナーの内容について軽くご紹介したいと思います！

新サービス「IDCFクラウド RDB」のご説明

まずはじめに、新サービスの説明を藤城より行いました。
▲「RDBの人」クラウド事業本部 ビジネス開発部 藤城 拓哉

「IDCFクラウド RDB」というサービスを、次の5つの観点から解説しました。

①料金
　・予算のサイジングがしやすい価格体系（RDBマシン料金 月額上限500円）
　・I/Oやリクエストによる従量課金はなし
②性能
　・VMwareによる高性能な基盤
　・オールフラッシュによる高速なディスクI/O
　・オールフラッシュのIOPS制限なし
③ネットワークレイテンシ
　・フェイルオーバー後でも変わらないレイテンシ
　・クラスタ配置調整で可用性も担保
④サービス断が生じるアクション
　・コンピューティング同様にダイナミックスケール
　・innodb_buffer_pool_sizeもオンライン変更
⑤ハイブリッド構成
　・スケール用や検証用などの一時利用に
　・閉域でセキュア、高帯域、冗長化、シームレス

SlideShareにも資料を載せておりますので、詳細はそちらをご覧ください！

「IDCFクラウド RDB」の技術説明

続いて、RDBのシステムアーキテクチャについて浅沼より説明しました。
▲クラウド事業本部 技術開発部 浅沼 敬

※浅沼の資料に関してはシステム内部情報を含むため、非公開とさせていただきます。ご了承ください。

RDBサービスの下記機能、オプションにおけるロジックなどを技術的な観点から説明しました。
・RDB作成時のホスト選択ロジック（冗長化オプション利用時）
・障害発生時のフェイルオーバー処理
・バックアップ取得
・マシンタイプ変更
・ディスクサイズ拡張

開発に関わるエンジニアから直接説明したことで、RDBの魅力である信頼性の高さが伝わったのではないでしょうか。

「IDCFクラウド RDB」のデモンストレーション

デモンストレーションでは、RDBの目玉機能の一つである無停止スペックアップをお見せしました！
・sysbenchを使ったOLTPテストをRDBマシンに対して実施
・RDBマシンをM4(2CPU/メモリ4GB)→L8(4CPU/メモリ8GB)に無停止スペックアップ
・スペックアップ実施時のレイテンシやエラーの有無を確認

▲無停止スペックアップのデモは、RDBマシンに対する負荷状況を可視化しよりわかりやすく

この他にも、冗長化オプションで実現可能なActive/Standby構成における、切り替わりのデモも行いました！

最後に

「IDCFクラウド RDB」はRDBマシン料金が500円/月と、気軽に試せる価格設定となっております。
機能や性能、開発の思いなどお伝えしたい点は尽きませんが、まずは実際に触ってみてください。
そしてぜひ、RDBに対する感想、ご意見、機能追加のご要望をいただければと思います！
RDBを皮切りに、今後もIDCFはさらにパワフルなクラウドを提供していきます！今後もご期待ください！

こんにちは藤城（@tafujish）です。RDB関連のエントリーは別の人が書いてくれたので、久しぶりにRDB以外の話をします。

最近、DR（Disaster Recovery）に関連したお問い合わせが多いため、IDCFクラウド上でのDR、つまり災害復旧を可能とする事前対策を紹介しようと思います。

ちなみに、DRやBCPといったワードについては用語集をご参照ください。

そもそも、IDCFではクラウドサービスを提供するずっと前から、DRを意識したデータセンターの建設を行ってきました。
www.idcf.jp
地震や台風など天災が多い日本では、DRに対して需要が多くあり、IDCFではクラウドサービスにおいても次のようなDRを意識したサービスを提供してきました。

• 東日本と西日本でのリージョン提供
• その東西間を接続するプライベートコネクト
• 東西分散したシステムを自動切り替えするためのGSLB

一方で、ドキュメントも提供しており、IDCFクラウド本の6.4章では、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）の考えから構成例までを紹介しています。
また活用マニュアルでは、MySQLレプリケーションによるデータ同期を用いたDRサイトの構築手順をwordpressを例に紹介しています。
www.idcf.jp

他にもsambaによるファイルサーバーを同期する方法を紹介しています。
www.idcf.jp

と、前置きが長くなりましたが、上述のとおり事前にDRを考慮した構成にしていれば問題はないのです。しかし、既存のサイトを急にDR対応する必要がでてくることもあると思います。そのようなときに、後追いでDRサイトを準備する具体的な方法を紹介していきたいと思います。（もしこれからサイトを構築する話であれば上記ドキュメントを参考にしてください）

# rsync [オプション] <コピー元> <コピー先>

# rsync -ahv /opt/backupfile root@192.168.1.97:/opt/

# ip route add 192.168.0.0/21 via 192.168.7.254 dev eno33557248

こんにちは！技術開発部の浅沼です！

先月、Forkwellさん とのコラボイベント「How Ruby performed Higher」を開催しました。

そこでは、『RubyでPub/Sub messaging 〜 Multi Process, Daemonizesしたアプリケーション開発の事例』と題して、 IDCFクラウドのサービスを実現しているバックエンドシステムのアーキテクチャと開発事例を紹介しました。

IDCFクラウドRDBやインフィニットLBのバックエンドシステムは、Rubyで開発したPub/Sub messaging を用いたアプリケーションが稼動しています。

RubyというとRuby on Railsを利用したMVCなWebアプリケーションを思い浮かべると思いますが、今回は Multi Process, Daemonizes を活用したスケーラブルかつハイパフォーマンスを目指したバックエンドシステムを紹介します。

バックエンドシステム構築のポイント

バックエンドシステムの構成を考える上で、リクエストとレスポンスの性能、スケーラビリティを考慮することが常に求められると思います。その要件を満たす一つの方法として、リクエストの非同期化が考えられます。

IDCFクラウドのバックエンドシステムにおいても非同期化は重要なポイントになります。各サービスの管理用DBやクラウド基盤の各種APIなど一つのサービスを実現するために、様々な連携サービスを利用します。

マネージドなサービスの場合、ユーザーに提供する仮想マシンには管理用のAgentサービスが稼動しています。そのAgentから各種状況に応じてイベントが発生したり、Agentへイベントを送信するなどの処理が発生したりします。サービスの利用拡大に応じて管理するAgent数の増減、発生するイベントの増減など、そのスケーラビリティにPub/Sub messagingという形はピッタリ当てはまりました。

高可用性を実現するマルチリージョン配置

可用性においてもPub/Sub messagingであることがポイントになります。Pub/Subで構築された各アプリケーションは、ロケーション上でも分散配置することが可能になります。

当社データセンターを活用してマルチリージョン上にアプリケーションを分散配置、Message Queueingを担うミドルウェアなどをクラスタ化して配置することで高可用性を実現することができました。

アプリケーションのスケーラビリティ、ハイパフォーマンス化

各アプリケーションのパフォーマンスやスケーラビリティ・可用性では、RubyとServerEngineの組み合わせを活用していることがポイントとなっています。

ServerEngineは、マルチプロセス化したアプリケーションに最適化された堅牢なRubyのフレームワークです。ServerEngineのSupervisorを利用することによって、プロセスの自動リスタートやコンフィギュレーションのダイナミックな再読込などが可能となっています。もし、稼動しているプロセスが異常終了したとしても、設定したプロセス数を維持するために新しいプロセスを自動的に起動してくれます。一台のサーバで必要な並列数を維持してパフォーマンスやスケーラビリティをコントロールしたい場合に、このServerEngineの特性が役に立ちます。

Railsでマルチプロセス化を行うと、一つのプロセスの使用メモリ量やオーバヘッドが気になりますが、Ruby+ServerEngineを利用することで、必要なgemのみを読み出すようにしています。実装は、クラスの構成から話すことも多く、常にコーディングスキルが鍛えられます。

以上のように、Pub/Sub messagingを活用したスケーラビリティと高可用性、Ruby+ServerEngineによるマルチプロセス化したアプリケーションのハイパフォーマンスを意識して日々開発に取り組んでいます。

おわりに

Rubyでマルチプロセスを活用したアプリケーション事例はなかなか珍しいようで、当日の参加者の皆さんには、Pub/Sub messagingのポイントやServerEngineの実用事例が好評でした。次回、機会があればPub/Sub messagingを利用したアプリケーション実装のハンズオンをやってみたいと思っています。

まだまだ、Message Queueingを担うミドルウェアの性能を引き出したり、各アプリケーションのクラス構成をよりスマートにしたり、インターフェースをより発展させたりなど、挑戦したいことはいっぱいあります。アーキテクトからミドルウェア、詳細設計・実装まで、一緒にRubyでアプリケーションを開発してクラウドサービスを実現することに興味のあるエンジニアを募集しています。詳しくは採用ページまで！

こんにちは藤城（@tafujish）です。今回は事例紹介をしたいと思います。
GPU担当として関わらせてもらった案件で、とても興味深かったので是非紹介したいなとお客様へ相談したところ快諾いただきました。

何が面白いかと言うと、DeepLearningでの利用を目的としたケースで、マルチクラウド化を実現しているというところです。今回はマルチクラウドに焦点を当てたいため、IDCFクラウドの導入事例ではなくこちらのブログで取り上げて、なぜマルチクラウドなのか、どのような構成なのかをヒアリングさせてもらった内容を私の方から紹介していきたいと思います。

今回のかたちでの掲載の承諾と情報提供くださったリクルートテクノロジーズ様に感謝申し上げます。

• そもそもの課題
• どんなサービスが動いているか
• 新環境検討のプロセス
• 環境移行のためのポータビリティ
• 環境移行して良かった点と見えた課題
• マルチクラウドを実現した構成
  • イメージ管理
  • Dockerホスト
  • ストレージ
  • ジョブ管理
• まとめ

こんにちは、クラウド事業本部SRE部の最上です。
主にクラウド基盤の運用業務・構築・サービス設計を担当しており、最近は海外でのカンファレンスにも積極的に参加し、最新の業界動向について知識を深めています。
だいぶ遅くなりましたが、今回は4月30日～5月3日にラスベガスで開催された「Dell Technologies World 2018」への参加レポートを記載したいと思います！

Dell Technologies World 2018 Conference | Las Vegas, April 30–May 3 | Dell EMC US

今後は、IDCFテックブログではあまりなかった、海外でのイベント参加レポートも積極的に投稿していくことにしました。
私だけでなく、社内の様々な部署の人が多くのイベントに参加しているので、きっとこういった投稿も多くなるはずです。 イベントの特性上あまり詳しくは書けませんが、概要や雰囲気をちょっとだけ紹介します。

参加の目的

イベント参加の目的は、「世界のトレンドを肌で感じる」ということです。

海外でのイベントは注目度が高く、世界中から様々な方が参加します。そのため、どのような技術が世界で注目されているのかがすごくよくわかります。
IDCFでは、Dell EMC社の「XtremIO」というFlashストレージをIDCFクラウドで利用していますが、 製品導入のきっかけが、こういったイベントに当時の製品設計者が参加し、説明を聞いたことでした。 インターネットで情報収集を行いトレンドを追うことはもちろんですが、イベントに参加して直接情報を得ることも重要ですね。

Dell Technologies Worldとは

Dell、EMC、VMwareなどのDell Technologiesグループ各社の製品だったり、ロードマップを紹介する場です。 セッション数は500を超え、何万人もの人々が集まる大きなイベントになります。

General Session

いわゆるメインセッションです。何万人という単位で収容可能な広い会場で開催されます。

Speaker Lineup | Dell Technologies World 2018 | Dell EMC US

CEOのマイケル・デル氏の講演は圧巻でした。 講演の内容に関しましては、様々なニュースサイトで取り上げられているのでそちらをご覧ください。

・「Dell Technologies World 2018」が開幕 - マイケル・デル氏が講演 | マイナビニュース
・ASCII.jp：マイケル・デル氏、デルテクノロジーズの「総合力」を強調 (1/2)

注目技術

以下のキーワードを含むセッションは特に人気がすごかったです。

• NVMe
• Storage Class Memory

これまでの接続規格であるSCSIやSATAなどの規格からNVMeへと変わることにより、よりSSDの性能を活かせるようになったことや、 3D XPointをはじめとする不揮発性メモリが登場したことによって、より注目を浴びているんだと思います。
また本セッションの前日に、All NVMe対応のPowerMAXという製品が発表されたので、その影響もあったのかもしれません。 座席は当然満席、立ち見も多くいる盛況ぶりでした。

実は2年前に開催された「EMC World」にも私は参加しており、イベントは終始「2016年はAll Flash Year！」という雰囲気で、All Flashに関連するセッションが多めでした。 その中の一つに「将来Flash技術は更に進化し、メモリとの距離が近づく」といった内容のセッションがあり、印象深かったのを覚えています。
あれから2年、PowerMAXのリリースがされ、いよいよ本格化してきたなという実感が湧くと同時に、たった2年でここまで技術の進歩があるのかという恐怖もあります。

少し裏話（5/4(金)の悲劇）

イベントは予定通り5月3日に終了しました。別件でアポがありサンノゼへ移動しようとしたのですが、まさかの飛行機が7時間遅延。 アポには間に合わないし、朝7時から空港のベンチで待っており足腰は痛いし散々でした。
しかし、航空会社からの補償で温かい食事をいただくことができました。 こういったアクシデントも海外あるあるですね。

最後に

本記事で、Dell Technologies World の雰囲気だけでも味わっていただけたかと思います。 IDCFでは役職者だけではなく、現場担当である社員でも積極的に海外イベントに参加できるためとてもよい刺激になります。 今後もイベントに参加した際は、本ブログで情報を発信していきたいと思います！

お久しぶりです、金井です。

本年も様々な情報を発信していきますので、引き続きよろしくお願いいたします。

2018年のIDCFは、データセンター・クラウド業界の「本場を知る」をキーワードに、42名の社員が12ヶ国、18のイベント/企業を訪問しました。 今後何度かに渡り、各イベントの参加レポートを当ブログで紹介していきます！みなさんご期待ください！

はじめに

本記事は、2018年4月30日から5月4日までデンマークのコペンハーゲンにて開催されました、KubeCon + CloudNativeCon 2018 Europeへの参加レポートです。コンテナOrchestratorとして、事実上のデファクトスタンダードとなったKubernetesやその周辺のエコシステムについて、最新情報を収集・体感することを目的として参加しました。
少しでも当日の雰囲気を感じていただけたらと思います。

なお、セッションの資料はイベントページのScheduleリストでセッションの詳細を選択するとダウンロードが可能です。（2019年1月時点）

KubeCon + CloudNativeCon 2018 Europe概要

• 日程：4月30日～5月1日：各種スポンサーイベント 5月2日～4日：本イベント
• 場所：Bella Center @コペンハーゲン（デンマーク）
• 規模：全体で4,300人の参加（過去最高）、日本人も40人以上参加

KubeCon自体は同時に最大11セッションが並行して行われるため、目的をある程度絞ってセッションを選ぶ必要がありました。私が参加したセッションは以下のジャンルです。

• 5月1日：OpenSDS Mini Summit
• 5月2日：KubeCon 2018 Europe（Istio、Service Meshのセッション中心）
• 5月3日：KubeCon 2018 Europe（CNIなどコンテナ間Networkのセッション中心）
• 5月4日：KubeCon 2018 Europe（コンテナの永続ストレージのセッション中心）

参加前の課題意識・モチベーション

KubeConに参加する前に私が思っていた課題意識・モチベーションは次のとおりです。私が根っからのインフラエンジニアであることから、アプリや利用例ではなく、本番環境への実装などインフラよりな内容がほとんどです。

• コンテナOrchestratorはKubernetesがほぼデファクトとなったが、Kubernetes上でService Meshという考え方、および実装の一つであるIstioが熱いので、その理由を把握する
• コンテナを本番利用ではインフラ（特にネットワークと永続ストレージ）の実装で課題が出てくると想定しているが、その課題と解消法について最新情報を知る
• CI/CD環境を実現して開発スピードを上げるためのヒントを探す

イベント内容の紹介

5月1日：OpenSDS Mini Summit

OpenSDS Mini Summitは、Huawei・IBMなどがスポンサーとなり、コンテナ環境でのPersistent Storage（不揮発性ストレージ）に関する話題を集めたサミットです。参加者は発表者含めて20名ほどでした。

OpenSDSとは

ストレージとアプリケーションの間のプラグインをオープン化しようとする取り組みのことです。

Home - OpenSDS

ストレージはベンダーの独自機能が多々あり、統一的なプラグインの開発は難しいとされています。ただ、Hyperscaleな基盤では様々なストレージを同じインターフェースで使うことにより、ユーザーにとってはストレージのベンダー依存性を減らすことができると期待されています。OpenSDSは、OpenStack用StorageやKubernetes環境でのPersistent Storageを提供するための利用が検討されています。

OpenSDS Mini Summit 2018 Copenhagenのアジェンダ

1. Introduction (by Steven Tan, OpenSDS TSC Chair, Huawei)
2. OpenSDS Aruba Release For OpenStack & Containers (by Rakesh Jain, OpenSDS TSC Vice-Chair, IBM)
3. Data Mobility For Hybrid Cloud Transformation (by Kei Kusunoki, NTT Communications)
4. OpenSDS 101: Introduction and Contribution Primer (by Xing Yang & Sean McGinnis, Huawei)
5. What is the Container Storage Interface (CSI) (by Saad Ali, Google)
6. LINSTOR: Reliable Storage for HA, DR, Clouds, and Containers (by Philip Reisner, Linbit)
7. Managing and Protecting Persistent Volumes For Kubernetes (by Xing Yang, Huawei)
8. SNIA Swordfish: Scalable Storage Management (by Alex McDonald NetApp, SNIA)
9. Storage Design & Operations for Hyperscale Environment (by Yusuke Sato, Yahoo Japan)
10. Storage Intelligence For The Data Center (by Allen Samuels, Western Digital)
11. The KPN Managed Hybrid Cloud DataExchange (by Wim Jacobs, KPN)

OpenSDS Mini Summitに参加しての所感

セッション開始前にアジェンダを見ると、日本・中国あたりのユーザー・コントリビューターが多いと感じました。すでにOpenStack基盤を持っており、OpenStackのストレージプラグインであるCinderや、Software Defined StorageのCephをKubernetes環境で引き続きどう使うか、という課題を持っているのではないかと推測されます。

OpenSDSは昨年度本格的に立ち上がったばかりのOSSプロジェクトのため、参加者数から見てもまだまだこれから、という感触を受けます。しかしコンテナを商用環境で利用しようとすると、ネットワークと永続ストレージの実装がどうしてもネックになり、簡単に既存のシステムをコンテナ化できないという事が頻繁に発生します。この課題意識と、それを解消しようとするコミュニティの方向性は間違っていないと思いました。
Kubernetesがデファクトスタンダードになった今、IaaS Orchestratorとして流行っているOpenStackがどうなるか、ちょっと心配していました。今回、OpenStack Cinder, Manilaで行われた、ベンダーが違っても同じAPIで操作できるようになる仕組みを、OpenSDSが再利用してKubernetes向けストレージとなっていくことが分かりました。全てを1から作るよりかなり現実的だと感じます。 こういった動きは普段の業務からは全く見えていなかったので、新しい学びを得ることができました。

5月2日～4日：KubeCon 2018 Day1～Day3

全体の雰囲気としては、Keynoteでも言われたように「CI/CD」が一番注目されているようでした。セッション会場も一番広い場所が確保されており、それでも人が溢れていました。

本当の意味でのMulti Cloud環境をシームレスに実現するためにはKubernetesでも足りず、Service Meshを形作るIstio、Istioのコントロール下でリクエストをコンテナ間で負荷分散するEnvoyの役割が大きくなっているように感じました。通信の負荷分散だけではなく、アプリケーションのバージョンなどに応じた負荷分散（カナリアDeploy、ABテストなど）もコントロールできるのがEnvoyの利点とのことでした。

あるセッション会場のアンケートでも、Kubernetesを本番商用環境で利用しており、さらに秒間1万リクエスト以上を処理する大規模環境での利用者も多くいました。

印象に残った話 -- Keynote - Day1 Evening

■GoogleによるgVisorの発表

コンテナでマルチテナント環境をセキュアに実装するために、1コンテナ1仮想マシンという実装が幾つかのHypervisorで提供されてきました。そのような状況に対してGoogleは、仮想マシンは不要であり、仮想マシンを作ることによるオーバーヘッドを無くしつつ、セキュアなコンテナを実現するgVisorというOSSを発表しました。gVisorに関する記事は様々なメディアで公開されていますが、Hypervisorなしで同等のセキュリティを担保するという仕組み、およびその実装の公開が衝撃的でした。当日の様子を視聴することができます。

■Anatomy of a Production Kubernetes Outage

Monzo Bankにて発生した実際の障害の詳細を紹介したKeynoteです。金融機関の決済システムに関わる基盤でのクラスタ全断障害である事もあり、Keynoteとしては非常に珍しく、参加者が皆静かに聞き入っていました。当日の資料と動画が公開されています。

根本原因はgRPCのバグだったが、それを誘発するKubernetes 1.6前後でのAPI仕様変化に伴うLinkerdとの連携不具合も組み合わさり、障害がKubernetesクラスタ全体に波及。さらに、障害対応をする人間の事象確認が不十分で、間違った順番でプロセス再起動を実施してしまい、長期間ダウンした事が説明されました。

教訓として、Defense in Depth(多層防御)をすることが大切と訴えていました。実際、例えクラウドが全断しても顧客サービスが停止しないようなシステム設計をしていたため、Kubernetesクラスタ全断という障害時も、顧客影響はほぼ発生しなかったとの事。また、もっと監視を細かく実装していれば不具合を未然に発見できたかも知れないという反省もあったとのことでした。

さいごに

イベントでのテクニカルな最新情報については各セッションで多くのインプットがあり、とても書ききれない状態でした。参加前の課題意識に対応する情報は次のとおりでした。

• Istioはとにかく便利。本番リリースが成功 or 失敗の二択ではなく、部分的にリリースできるというのは精神的にも楽だし、開発の人はサービス間のネットワーク構成などを意識する必要がないため開発が捗る
• コンテナネットワークについては、CNIなどのコントロールプレーンがかなり成熟してきている。しかしストレージについては、2017年頃からKubernetesの永続ストレージが本格的に実装されてきているので、まだまだこれから。OpenStack Cinderとの連携というアプローチは、既存資産がある人にとっては朗報
• CI/CDについて、1日10回は本番Deployできるような文化にしなければビジネスの変化についていけない。ただし、KubernetesやCI/CDツールを導入することが目的ではなく、どんなスピードでビジネスの変化に対応するサービス開発をしたいのか、を先に考えるべき

引き続き、Kubernetes界隈の情報は積極的に拾っていこうと思っています。
本記事の締めとして、ネットワークや永続ストレージの実装に興味のあるインフラエンジニアの目線で、どんなセッションを選択したのかを掲載します。

Day1 参加セッション一覧

1. Keynote - Day1 Morning
2. Introduction to Istio Configuration - Joy Zhang, Google (Beginner Skill Level)
3. Practical and Useful Latency Analysis using Istio and OpenCenus - Varun Talwar, Stealth Startup & Morgan McLean, Google (Intermediate Skill Level)
4. Replacing NGINX with Envoy in a Traffic Control System - Mark McBride, Turbine Labs, Inc (Advanced Skill Level)
5. Building Hybrid Clouds with Istio - Allan Naim, Google & Rohit Agarwalla, Cisco (Intermediate Skill Level)
6. Performance and Scale @ Istio Service Mesh - Fawad Khaliq, VMware Inc, Laurent Demailly, Google & Surya V Duggirala, IBM (Intermediate Skill Level)
7. Jenkins X: Easy CI/CD for Kubernetes - James Strachan, CloudBees (Intermediate Skill Level)
8. Keynote -Day1 Evening

Day2 参加セッション一覧

1. Keynote - Day2
2. How to Get a Service Mesh Into Prod without Getting Fired - William Morgan, Buoyant, Inc (Any Skill Level)
3. Kubernetes and the CNI: Where We Are and What's Next - Casey Callendrello, CoreOS (Intermediate Skill Level)
4. GitOps for Istio - Manage Istio Config like Code - Varun Talwar, Stealth Startup & Alexis Richardson, WeaveWorks (Intermediate Skill Level)
5. Global Container Networks on Kubernetes at DigitalOcean - Andrew Sy Kim, DigitalOcean (Intermediate Skill Level)
6. CNI Intro – Bryan Boreham, Weaveworks & Casey Callendrello, CoreOS (Any Skill Level)

Day3 参加セッション一覧

1. Keynote - Day3
2. Kubernetes Storage Lingo 101 - Saad Ali, Google (Beginner Skill Level)
3. Using Kubernetes Local Storage for Scale-Out Storage Services in Production - Michelle Au, Google & Ian Chakeres, Salesforce (Intermediate Skill Level)
4. Container Storage Interface: Present and Future - Jie Yu, Mesosphere, Inc. (Intermediate Skill Level)
5. Istio Tells me my Service has Slow Response Time, Now What? - Endre Sara & Enlin Xu, Turbonomic (Any Skill Level)
6. Everything you Need to Know about Using GPUs with Kubernetes - Rohit Agarwal, Google (Intermediate Skill Level)
7. Vitess and a Kubernetes Operator - Sugu Sougoumarane, YouTube (Intermediate Skill Level)

はじめまして、クラウド事業本部 技術開発部の本間です。

KubeCon+CloudNativeCon 2018 Europe 参加レポートに続き、7月24日〜26日に行われたGoogle Cloud Next ’18 San Franciscoの参加レポートを当ブログで紹介します！

Google Cloud Platform™（以下GCP™）は当社と同じクラウドコンピューティングを提供しており、今後の当社のサービス展開の参考になればと思い参加しました。

Nextについて

今回のNextの規模
・来場者数 23,500 人以上
・6会場
・500以上の講演数
2017年の同イベントと比較すると2倍近いスケールになっていました。また音楽や映像の演出、技術的なセッション以外の音楽イベントなどさまざまでした。

会場のMosconeセンターです。6会場のマップです。

内容についてはGoogle Cloud Platform™とG Suite™に関するイベントになっており、次の8つのテーマごとにさまざまな講演がありました。

• Application Development
• Collaboration & Productivity（G Suite™）
• Data Analytics（BigQuery™など）
• Infrastructure & Operations
• IoT
• Machine Learning & Artificial Intelligence（ML、AI）
• Mobility & Devices（Chrome OS™）
• Security

また、たくさんのパートナーによるブースが会場には並んでおりました。

基調講演

基調講演は3日間に渡って、朝9時から1時間30分づつ行われ、さまざまな新サービスの発表が行われました。最初にダイアン・グリーン氏が登場し、 その他にもたくさんの方が、登場しておりました。Google™ CEOのスンダー・ピチャイ氏も出てきました。

私はまだGCP™に触り始めたばかりでしたので、どのサービスが本当に初めての登場なのかが、聞いただけでは判断できませんでしたが、会場の雰囲気や歓声でなんとなくわかりました！

上の写真のようにコンテナを意識したような箱型のディスプレイが4つならんだ会場で基調講演が行われ、周辺サービス含め、コンテナ一色という感じでした。

基調講演の詳細な内容はGoogle Cloud™ Japanのブログにまとまっておりますので、そちらをご参照下さい。

Cloud Services Platform

次は今回のNextの中でも注目が高かった発表の1つのCloud Services Platformについてです。同じIaaSサービスを展開する当社としても興味がある部分です。簡単に言うと、コンテナまわりをまとめて便利にしたプラットフォームという感じです。各キーワードに対して、Cloud Services Platformが提供するのは次になります。今回、新たに3つの新サービスが発表され、コンテナを使用する上で網羅されたイメージです。

• サービスメッシュ：Mnaged listio
• コンテナのポリシー管理：GKE policy management
• ハイブリッド：GKE On-Prem（new）
• DevOpsツール：Stackdriverへの対応
• サーバーレス：knative（new）
• デベロッパーツール：Cloud Buildのgithub連携（new）

GKE On-Prem

その中でも今回発表されたGKE On-Premの発表が一番興味深かったです。Google Kubernetes Engine（GKE）をオンプレミスでも使用できるというサービスで、当社のデータセンターにあるサーバーやVMとも親和性が高そうです。

背景として、80%の企業がマルチクラウド（オンプレミス含む）戦略を取っているが、クラウドサービスごとに操作や設定の方法が異なり、IT管理者の管理コストが83%も増え続けています。（IT管理者がセキュリティやモニタリングをクラウドごとに操作を覚えて設定し、管理が必要。）このような問題を解決するために、同じ操作で統一した管理が出来るよう、GKE on-premが発表されました。

次はセッションで説明された内容です。

構成

まず、最初に構成イメージは次の画像です。右側が「your Data」となっており、構成自体はGKEとすべて同じです。

KubernetesのバージョンはGKEと同じバージョンが使用でき、パッチ適用など最新の状態に保ってくれます。
また、GCP™のStackdriverでオンプレにあるKubernetesのログも統一して管理できます。個人的にはStackdriverが使いやすいので、オンプレもまとめて管理できるのは嬉しいです。

デモ

次にGCP™のコンソールからオンプレミスのKubernetesクラスタをGKEに登録するデモが実際にNextのセッションで行われたので紹介します。

オンプレミスのKubernetesクラスタをGKEに登録するところです。GCP™のコンソールからの登録可能です。 GKE Connectを選択し、manifestをダウンロードし、kubectl createコマンドを実行します。 認証後、クラスタが登録されます。

接続後、リスト上にオンプレミスのKubernetesクラスタがリストアップされています。 （リストの四角い枠で囲まれているのがオンプレのKuberntesクラスタになります。）

今後の展望

GKE On-Premを使うと、今後当社のデータセンターにあるサーバーやVM（※1）も、GKEを使ってGCP™上で統一して管理が出来るようになり、GCP™とGKEでマルチクラウド構成のクラスターが簡単に組めるようになると思います。
もし、当社のVMとGKEのクラスタ構成が組める場合は、次のイメージとなると思います。
※1：サーバーやVMのH/W、S/W、NWの要件については今後、調査が必要です。

興味がある方はGoogleのGKE On-Premのページでα版のEARLY ACCESSの登録が開始されていましたのでご登録してみてはいかがでしょうか。 リリースされましたら、当社でもぜひ試してこのブログに掲載したいと思います。

最後に

本場のイベントはスケールが大きく、熱気もすごかったです。日本では1社のイベントでもなかなかこのような規模のイベントはないのかなと思います。 是非、皆様も機会があれば4月にサンフランシスコで行われるGoogle Cloud Next '19に参加してみて下さい。

また当社は、9月19日に日本で開催されました Google Cloud Next '18 Tokyoの基調講演で、Google Cloud Platform™ の「マネージド サービス プロバイダー」に認定されたことが発表されました。 今後、「IDCFクラウド」とGoogle Cloud Platformのプロダクト連携を進めていく予定です。

詳しくは下記の案内をご参照下さい。

www.idcf.jp

そして第一弾として、Google Cloud Storage™️の基盤に採用したクラウドストレージを11月にリリースしております。 今後も新サービスを皆様にお届けしていきたいと思いますので、お楽しみに！

Google, Google Cloud, Google Cloud Platform, GCP, Google Cloud Storage, BigQuery, G Suite, Chrome OS, ApigeeはGoogle LLC の商標または登録商標です。

こんにちは！技術開発部の浅沼です。

今回は、2018年度に購読した書籍からこの1年間を振り返り、IDCFクラウドの開発を通じて身についた技術要素ついて紹介したいと思います。

1冊目：「みんなではじめるデザイン批評」

IDCFクラウドでは、『究極の使いやすさ』を合い言葉に、UIや機能を考え開発を進めています。IDCFクラウドの開発に入って初めに驚いたのは、UIデザインに対するレビューのきめ細やかさでした。ただ、開発チームメンバーはレビュー時に意見を出しにくかったり、ときにはレビュー者の主観ともなりがちな意見も出たり、そのなかでユーザーにとってもっとも価値あるものは？という主題に沿って全体をファシリテーションしていく難しさもありました。
そんな中、デザインレビューの進め方の参考にしたのがこの書籍でした。批評・フィードバックの仕組み、批評をプロセスに取り込むことなど、すぐに活かせることが多い内容です。今では、スプリント計画やレビュー時に、デザインから機能を検討し批評を行うことが浸透しつつあります。

「みんなではじめるデザイン批評　目的達成のためのコラボレーション&コミュニケーション改善ガイド」
著者：アーロン・イリザリー、アダム・コナー
翻訳：安藤貴子
出版社：ビー・エヌ・エヌ新社

2冊目：「ノンデザイナーでもわかる　UX＋理論で作るWebデザイン」

1冊目のデザイン批評を購読した私自身は、実はノンデザイナーです（サーバサイドエンジニア主体のキャリア）。ですが、『究極の使いやすさ』を実現する一員として、UX（ユーザーエクスペリエンス）についても考え方を持っておく必要を感じ、最初の入門で手にした1冊がこちらの本になります。UX設計に始まり、UX設計からUIデザインにつなげていく考え方を体感できる1冊です。このおかげでIDCFクラウドのUXとは？クラウドのコントロールパネルに求められることは？なぜ、そのUIデザインなのか？ちょっとずつですが、突き詰めて考えていく思考の癖がついて来たと思います。

「ノンデザイナーでもわかる　UX＋理論で作るWebデザイン」
著者：川合 俊輔、 大本 あかね
監修：菊池 崇
出版社：マイナビ出版

3冊目：「プロダクションレディマイクロサービス」

IDCFクラウドの運用には、SREや統合監視、カスタマーサポートなど、組織で体制を整えて日々の運用・監視を行っています。サービス開発の中でも、リリースまでに運用の構築を協力して行うことが多々あります。特に近頃は、サービスごとにアプリケーションを分けてサービス単体でのデプロイサイクルを運用できるように取り組んでいます。多種多様なサービス/アプリケーションが増える中で、運用のしやすさ・強固な体制作りに課題を感じて購読した本になります。プロダクションレディの考え方、そして、組織的な理解を高めるためのドキュメンテーションは非常に参考になりました。アーキテクチャや開発基準を検討する際に、この書籍で振り返ることが多々あります。

「プロダクションレディマイクロサービス　――運用に強い本番対応システムの実装と標準化」
著者：Susan J. Fowler
監訳：佐藤 直生
翻訳：長尾 高弘
出版社：O'Reilly Japan

4冊目：「マスタリングTCP/IP」

IDCFクラウドのサービス開発は、TCP/IPの仕様に関する知見や仕様を必要とするシーンが必ずあります。TCP/IP全般についておさらいするには、やはりこの本だろうと思います。どの機能もサービス仕様書などにおいて、何ができるのか、どんな仕様で提供するのか、しっかりと説明できる状態にしておくことが重要と考えています。基礎的なことかもしれませんが、ネットワークを支える重要なプロトコルですので、理解を深め続けたいと思っています。

「マスタリングTCP/IP 入門編　第5版」
著者：竹下 隆史、村山 公保、荒井 透、苅田 幸雄
出版社：オーム社

5冊目：「Real World HTTP」

ロードバランサやCDN関連のサービス開発がきっかけで、HTTPの理解を深めておく必要を感じて購読した本になります。Webサービス開発経験の中でHTTPに関する知識・経験は得ていたのですが、改めてHTTPの各バージョンにおける背景・変遷をたどっていくことで、多少あやふやな理解もあったところが補えました。特にTLSについての理解に大変役立ちました。HTTP/2, HTTP/3と発展していく中で、サービス提供するときも仕様のメリットを最大限活かせるようにしたいと思います。

「Real World HTTP　――歴史とコードに学ぶインターネットとウェブ技術」
著者：渋川 よしき
出版社：O'Reilly Japan

6冊目：「Kubernetes実践入門 プロダクションレディなコンテナ＆アプリケーションの作り方」

このブログを書いている時点で、ごく最近手にしたばかりの書籍です。Japan Container Daysに参加したときも、開発環境まではコンテナ化していますが、本番環境もコンテナで運用していると手を上げた方は、まだまだ多くはなかったと思います。コンテナ化した開発・運用のメリットは多々あると思います。しかし、開発から本番環境までを一貫してコンテナ化した運用まで持っていくには、まだまだ大変なことが多いのかなと感じました。そこで、この書籍にあるプロダクションレディに惹かれて手に取りました。まだ読み進めている最中ですが、本番環境で運用するためにKubernetes上で必要なポイントが分かりやすく網羅されていると思います。

「Kubernetes実践入門 プロダクションレディなコンテナ＆アプリケーションの作り方」
著者：須田 一輝、稲津 和磨、五十嵐 綾、坂下 幸徳、吉田 拓弘、河 宜成、久住 貴史、村田 俊哉
出版社：技術評論社

まとめ

2018年度に購読した書籍の一部を紹介させてもらいました。こうして振り返ってみますと、UIデザイン・UX、マイクロサービス運用とプロトコルの基礎、そして、注目されているコンテナ/Kubernetesまで、幅広く知識を広げた一年でした。IDCFクラウドのアプリケーション開発に携わりますと、いずれのサービスもインフラやネットワークを支える基盤技術と関わりますので、必然的にプロトコル知識などを掘り下げたくなります。また、どのサービスも究極の使いやすさを目指す過程で、UXに基づいてUIデザインをレビューし合う時間ができますので、これも知識を深めたくなる分野です。IDCFクラウドのアプリケーション開発は、UI・アーキテクト・基盤技術と網羅的に得られる機会が多いと思います。この経験を活かして、IDCFクラウドのアプリケーション開発におけるスキル獲得のトレイルマップなど描いてみたいと思います。

こんにちは、藤城（@tafujish）です。
昨年度、スパコンやHPCの学会＋展示会のSC(Supercomputing Conference)18に参加してきたので紹介します。
sc18.supercomputing.org

こんにちは、藤城（@tafujish）です。
前回SC18のエントリーを書きましたが、そのSC18にてお会いしたR-CCSの松岡センター長からのお誘いで、スーパーコンピュータ「京」の見学と情報交換の機会をいただきました。IDCFからはデータセンターのファシリティ担当やクラウドの担当など大勢で参加させていただきました。
京の見学レポートは既に多くの方が公開されていますので、ここでは我々が運営するデータセンターと京についての違いを紹介したいと思います。

京の見学

今回は計算機室の中に入ることができ、稼働中のマシンを間近でみることができました。計算機室の中は思っていた以上に寒くなく、うるさくもなかったです。水冷の効果ですね。

「京」と書かれた赤いパネルのラックはよく見ますが、京の裏側はどうなっているかスパコン好きとしては気になりますよね？京の裏はこんな感じでした。

ラックの周囲は結構余裕があるスペースになっており、柱が1本もない広大な空間に驚きでした。データセンターだとフロア内に柱が何本も立っていますからね。
IDCFのクラウド担当のメンバーは興味深々で見学しました。

一方でIDCFのファシリティ担当は、空調機械室や熱源機械棟に興味津々で、R-CCSメンバーとの会話も盛り上がっていました。

はじめまして、クラウド本部 クラウドSRE部の森田です。

4月18日〜20日に福岡で行われた「RubyKaigi 2019」の参加レポートを紹介したいと思います！

当社では以前Rubyエンジニア必見！IDCFクラウドのバックエンドシステムアーキテクチャでご紹介したように、IDCFクラウドRDBやインフィニットLBのバックエンドシステムにRubyを使用しております。 今回、IDCFでは私を含めた4名のRubyエンジニアが、Rubyの最新の動向をキャッチすべくRubyKaigiに参加しました。

RubyKaigiについて

RubyKaigiは年に1回開催されているプログラミング言語Rubyの国際カンファレンスです。

• 来場者数 1,500人
• セッション数 66
• 開催場所 福岡国際会議場

プログラミング言語の国際カンファレンスですと海外での開催が多いかと思いますが、Rubyは生みの親であるまつもと ゆきひろ(Matz)さんが日本人と言うこともあり、国内でのイベントや活動が活発という特徴があります。

セッション

いくつかセッションをピックアップしてご紹介します。

Keynote(Matz)

最初はMatzさんのKeynoteから始まりました。内容は主にRuby3に向けたRubyの今後の話でした。

• 私はテストが嫌い、なぜならDRYじゃないから
• 私達はプログラムが書きたいのであってテストをかきたいわけじゃないが、仕方がないので人類はテストを書いている
• Ruby3では型チェックの導入を考えている
• frozen_string_literalについてはRuby3でデフォルト化する話が以前から上がっていたが、Ruby2系との互角性問題がありRuby3への導入は見送ったとのこと

Performance Improvement of Ruby 2.7 JIT in Real World(Takashi Kokubun)

speakerdeck.com

Ruby2.6でリリースされたJITコンパイラが2.7で改善したという話。JITコンパイラの仕組み自体についてはまだ私自身理解できていないですが、Ruby3に向けたJITコンパイラの改善は着々と進んでいるように感じました。

• Ruby2.6ではJITを有効にするとベンチマーク比で1.6倍の速度が出る
• ただしRailsなどを使用している実際の環境では、JITを有効時の方が逆に遅くなるというベンチマーク結果が出ている
• Ruby2.7ではいくつかの改善を導入し、Rails使用時でもJIT無効時と速度的に大差がなくなってきた

All bugfixes are incompatibilities(nagachika)

Rubyの安定版メンテナーとして、その仕事と適正、失敗談を聞くことができました。 ちなみにRuby本体はSVN + Redmineの環境で開発されていたみたいですが、Kokubunさんによると今後はGitに移行しSVNは使わなくなるとのことでした。

• Rubyはstable versionごとに一人メンテナーがいて、trunkに入ったbugfixを担当しているversionにbackportするのが仕事
• どのbugfixをbackportするかの取捨選択が肝であり、メンテナーとして問われるところ
• 箇所によってはbackportしたことで逆にデグレが起こることもある(syntax error改修で別のsyntax error・・・とか)ので、むやみやたらに取り込むことはできない
• 影響範囲の広さ、不具合の深刻度、発生条件の希少性などを参考に、安定版の維持を最優先に現実的な判断をする

Better CSV processing with Ruby 2.6(Kouhei Sutou/Kazuma Furuhashi)

slide.rabbit-shocker.org

Rubyに内包されているCSVライブラリについて、2.6にバージョンアップでの改善の取り組みについてのセッションでした。
IDCFクラウドのインフィニットLBは、バックエンドで使用しているRubyのバージョンを2.5系に引き上げたばかりでしたが、早く2.6系にバージョンアップしたいと思える内容でした！ こういった、内部ライブラリのコミッターの方々の話が聞けるのもRubyKaigiならではだと思いました。

• 2.5.xと比べてパースは約2倍、書き出しは約2.5倍まで高速化された
• CSVに書き込むときはCSV.generate_lineよりCSV.<<のほうが10倍速い！

技術書コーナー

技術書コーナーには、IDCFのインフィニットLBの開発に協力頂いている五十嵐さんの入門書が多数展示されておりました!

なお、こちらの「RubyとRailsの学習ガイド」はboothにて電子書籍版が500円で入手可能なようです。

エディタ投票

gifteeさんがエディタの投票企画を開催していました。

VimとEmacsではVimの圧勝です。(ちなみに私はRubyMine)

VSCodeの人気も高くなってきているようです。シールが整列して貼られているあたり、VSCode使いはきっと良い人達！（社内のVSCode使用者談）

Party

初日のセッション終了後、シャトルバスに乗って川端商店街に移動しました。 IDCF大阪メンバーと合流し、なんと商店街を貸し切ってのパーティーに参加しました！

https://rubykaigi.org/2019/docs/rubykaigi-official-party.pdf

ネットニュースにもなったのでご存知の方も多いと思います！（社内でも話題になっていました） 商店街の飲食店からご提供いただいた食べ物や九州の地酒たちに舌鼓を打ちつつ、参加者の方と交流するなど楽しい時間でした。

最後に

来年のRubykaigiの場所は長野県松本市になりました。

RubykaigiはRuby自体の内部実装やC言語の話も多く、Ruby初心者の方は敷居が高く感じるかもしれませんが、After Partyや協賛企業のブースなどRuby初心者でも楽しめるイベントが沢山あります。
Rubyに関わる方、少しでも興味がある方はぜひ来年参加してみてください！

こんにちは、クラウドSRE部の菅原です。

エンジニアの皆さんはサーバーのレスポンスタイムなどの速度計測を行っていると思いますが、ブラウザ側で要素が描画される時間は計測できておりますでしょうか？

今回は、ブラウザ上で 画面が表示されてから操作可能になるまでの速度を計測し、Google Analytics で可視化する対応について説明します。

背景

IDCFクラウドの仮想マシン一覧で保有しているVMの数が多いと、JavaScriptの処理が画面を30秒以上ロックしてしまう現象が発生しました。

お客さまの報告から発覚したことですが、「遅い！」というキーワードから連想するのはサーバーのレスポンスタイムという先入観があったので、そのような状況に気づけませんでしたし、フロントエンドの速度を計測していない状態での調査は大変でした。JavaScriptの処理を修正し、遅いという問題は改善しましたが、今後このような事態を分析できるデータが必要だという課題が残りました。

これらを改善したいという思いから、この対応に取り組みました。

計測方法

ブラウザの処理時間を計測するためにJavaScriptのperformance.getEntriesByType()メソッドを使用します。
performance.getEntriesByType('navigation')[0]を実行すると以下のようなデータが取れます。
これらは、ブラウザが検知しているイベント発生時点の経過時間をミリ秒単位で記録したものです。

connectEnd: 10.900000001129229
connectStart: 10.900000001129229
decodedBodySize: 177316
domComplete: 370.43000000267057
domContentLoadedEventEnd: 214.36000000539934
domContentLoadedEventStart: 214.02500000112923
～ 中略 ～
requestStart: 12.945000002218876
responseEnd: 15.859999999520369
responseStart: 13.275000004796311
～ 略 ～

画面が表示されてから操作可能になるまでの速度を、上記の responseEndとdomContentLoadedEventEndを用いて以下のJavaScriptで表現すると、処理時間timeは198(ms)となりました。(小数点以下は切り捨て)

var perform = performance.getEntriesByType('navigation')[0];
var time = Math.floor(perform.domContentLoadedEventEnd - perform.responseEnd);

Google Analytics へ送信する

上記の値は Google Analytics のカスタム速度へ送信することにしました。
以下のような記述で送信することができます。(analytics.js を読み込んでいる前提)

window.addEventListener('load', function () {
    try {
        // パフォーマンスの情報取得
        var perform = performance.getEntriesByType('navigation')[0];
        var time = Math.floor(perform.domContentLoadedEventEnd - perform.responseEnd);

        // gaのカスタム速度へ値を送信する
        ga('send', {
            hitType: 'timing',
            timingCategory: 'DOMContentLoaded',
            timingVar: location.pathname,
            timingValue: time,
            timingLabel: label
        });
    } catch (e) {
        // 例外処理
    }
});

上記データの収集だけでも良いのですが、今回はコネクションの情報も送信するように対応しました。

responseEndからdomContentLoadedEventEndまでの時間にはjs、cssなどのファイルをダウンロードする時間も含まれております。
ユーザーの環境で回線速度が遅かった場合にはjs、cssなどのダウンロード時間が大きくなってしまうため、コネクションの情報も収集することで調査の指標とすることが狙いです。

コネクションの情報は、以下の記述で取得することができます。(Google Chrome のみ)

var connectionInfo = '';
if (navigator.connection) {
    var connection = navigator.connection;
    connectionInfo = JSON.stringify({
        'downlink': connection.downlink,
        'effectiveType': connection.effectiveType,
        'rtt': connection.rtt,
        'saveData': connection.saveData
    });
}

コネクションの値はGoogle Analyticsのカスタムディメンションに設定することにしました。
カスタムディメンションは Google Analytics >「管理」>「プロパティ」>「カスタム定義」>「カスタムディメンション」で作成できます。

以下の記述で完成です！

window.addEventListener('load', function () {
    try {
        // パフォーマンスの情報取得
        var perform = performance.getEntriesByType('navigation')[0];
        var time = Math.floor(perform.domContentLoadedEventEnd - perform.responseEnd);
        var connectionInfo = '';

        // コネクションの情報を取得
        if (navigator.connection) {
            var connection = navigator.connection;
            connectionInfo = JSON.stringify({
                'downlink': connection.downlink,
                'effectiveType': connection.effectiveType,
                'rtt': connection.rtt,
                'saveData': connection.saveData
            });
        }

        // gaのカスタムディメンションにコネクション情報を設定
        ga('set', 'dimension1', connectionInfo);

        // gaのカスタム速度へ値を送信する
        ga('send', {
            hitType: 'timing',
            timingCategory: 'DOMContentLoaded',
            timingVar: location.pathname,
            timingValue: time,
            timingLabel: label
        });
    } catch (e) {
        // 例外処理
    }
});

Google Analytics では以下のように表示されます。

まとめ

いかがでしょうか？
フロントエンドの速度計測はなかなか奥が深いですよね。 上記の対応で画面が表示されてから操作可能になるまでの速度について分析できるようになり、フロントエンド側の速度低下に気づけるようになりました。 速度だけではなくネットワークコネクションの情報も収集したことで、より分析の精度を高められたと思います。

IDCFクラウドでは、このようなデータを基に今後の改善に役立てていきたいと考えています。
さらに今後はjs、cssファイルのダウンロード時間など、より細かい速度について計測できるような仕組みを考えていけたらと思います！

こんにちは、クラウド推進部の菊地です。

今回は4月から6月までにリリースされた機能についてピックアップしてご紹介します！

• 新機能について
  • 【RDB】パラメーターグループ機能
  • 【コンピュート】仮想マシン作成時のユーザーデータ入力対応
• 機能改善について
  • 【ILB】Mackerelによる監視項目追加
  • 【ILB】インフィニットLBの性能が1.6倍に向上
  • 【コンピュート】ユーザーデータのサイズ制限緩和
  • 【コンピュート】標準提供のテンプレート（CentOS, RHEL）の追加
• 仕様変更について
  • 【クラウドコンソール】トップページデザイン変更
• まとめ

新機能について

まずは新機能についてご紹介します。 4月には2つの機能が新たに追加されました！

【RDB】パラメーターグループ機能

4月17日にリリースされたのはRDBのパラメーターグループ機能です。

RDBにてパラメーターをテンプレートベースで編集できるようになり、ユーザー任意のチューニングが可能となりました！

パラメーターグループについては下記の方法でRDBに割り当てることができます。

1. RDBのダッシュボードの「パラメーターグループ」をクリックすると「パラメーターグループ」画面へ遷移します。 画面右上の「パラメーターグループ作成」をクリックします。

2.「パラメーターグループ名」と「パラメーター」を設定し、「確認画面へ」 - 「作成」の順にクリックするとパラメーターグループが作成されます。

3.RDBトップページにて対象のRDBを選択し、「パラメーターグループ」タブの「パラメーターグループ設定」プルダウンにて作成したパラメーターグループを選択します。 「変更する」をクリック後、RDBを再起動すると割り当てたパラメーターグループが反映されます。

【コンピュート】仮想マシン作成時のユーザーデータ入力対応

これまでAPIでのみ提供していた仮想マシン作成時のユーザーデータの入力ですが、4月24日以降からはクラウドコンソール上からも入力可能となりました。

これにより、cloud-initなどと連携することが可能となります。

cloud-initについても今後IDCFクラウドの各種標準テンプレートで標準搭載する予定になっています。

ユーザーデータは下記の手順にて入力できます。

1.コンピュートのダッシュボードにて「仮想マシン作成」をクリックすると「仮想マシン作成」画面へ遷移します。

2.「詳細情報」項目の「拡張機能」の矢印をクリックします。

3.「ユーザー情報」欄にユーザー情報を貼り付けます。 このとき、エンコード前の元のテキストを利用する場合は「base64エンコードを使用する」にチェックを入れてください。

※ユーザーデータについての詳細はこちらを参照ください。

機能改善について

各サービスについても機能改善を行って着実にパワーアップしています！

【ILB】Mackerelによる監視項目追加

4月11日にはインフィニットLBのMackerel監視項目へのHTTPステータスコード（Statuses）の追加情報が更新されました。

ご利用時は以下のような画面イメージとなります。

【ILB】インフィニットLBの性能が1.6倍に向上

さらに、4月17日にはインフィニットLBのスケールを5台から8台に引き上げています。

またノードあたりのコネクション数も増強し、新規に作成したインフィニットLBでは最大のコネクション数が従来の76,000から128,000に向上しています。

【コンピュート】ユーザーデータのサイズ制限緩和

新機能として先述していた仮想マシン作成時のユーザーデータ入力機能については、テキストサイズ制限が緩和されました。

以前まで、3の倍数のテキストサイズ制限がかかっていましたが、4月24日以降からはその制限はなくなっています。

ただしエンコード前のテキストサイズについては、クラウドコンソール上で利用した場合、2KBの制限があるのでご注意ください。

【コンピュート】標準提供のテンプレート（CentOS, RHEL）の追加

6月14日からは、以下のテンプレートが標準提供されています！

• CentOS 7.6 64-bit
• CentOS 7.6 64-bit for Vagrant
• [GPU BOOST] CentOS 7.6 64-bit
• RHEL 7.6 64-bit

仕様変更について

【クラウドコンソール】トップページデザイン変更

6月12日からIDCFクラウドのトップページデザインが少しだけ変化していることにお気付きでしょうか？

▼以前までのトップページ画面

▼アップデート後のトップページ画面

今まで画面上部にあったリージョン選択欄がなくなり、すっきりした印象になりました。

各サービスのアイコンもコンパクトになった分、余計にスクロールしなくてもサービス全体が見えるようになりましたね。

リージョンは各サービス画面遷移後に選択できます。

まとめ

今回は4月から6月までにリリースされた新機能などをピックアップしてご紹介しました！

リリース情報はこちらからもご確認いただけます。

今後ともIDCFクラウドのさらなる進化にご期待ください！

こんにちは、クラウドSRE部の志甫谷（しほや）です！
IDCFクラウドの課金系システムをメインで担当しています。趣味はフットサル（プレー・観戦）です。

まえがき

春先になると、いつも思い出すことがあります。それは、自分が新卒1年目だった時のことです。
社会人としての経験を積み年次を重ねていく中で、毎年この時期は必ず1年目の新鮮な気持ちを思い出すのです。

これからお伝えするのは、新鮮な気持ちを抱きながら
社会人1年目を迎えた4人の新卒メンバーのお話であり、
IDCFに嵐を巻き起こす、夢と希望に溢れた
新卒エンジニア4人の果てしない挑戦の記録です！

※このまえがきは、【目指せ！Fの頂】*1のパロディです。

新卒チーム開発研修概要

この研修では、クラウド本部に配属された4名の新卒メンバーが約2ヵ月間でチーム開発を行い、Webアプリケーションの完成を目指します。

体制

研修の目的

新卒

• チーム開発経験を積む
  • 設計/実装/リリースなどの各フェーズを体験する
  • タスク分担をしてプロジェクトを進行させていく
  • 期限を意識した仕事の進め方を学ぶ

チューター

• プロジェクトマネジメントの経験を積む
  • PMとして稼働調整や工数管理をしながらプロジェクト管理をする
  • テックリードとして技術面で新卒をサポートし、プロジェクトを円滑に進める

予定スケジュール

7月

イベントは「 Google Cloud Next ’19 in Tokyo 」に参加予定です。Googleの最新技術を学びます。

8月

9月

この記事では、要件定義が終わり開発テーマが決まるところまでをご紹介します。

キックオフ

キックオフでは、プロジェクト概要をメンバーに展開しました。
これからの2ヵ月間に対する期待や不安が入り混じったメンバーの表情が印象的でした。

GitHub研修

テックリードである篠田を講師として、GitHubの入門となるインプットを行い、後半は実践形式でGitHubを操作してもらいました。

インプット内容

• バージョン管理がなぜ必要か？
• Gitでできることは何か？
  • clone
  • fork
  • pull
  • push
  • branch
  • commit
  • merge
• GitHubでできることは何か？
  • pull request
  • issue
• 開発フローについて
  • Gitフロー
  • GitHubフロー

不慣れなコマンド入力を克服する！という高いモチベーションをメンバーから感じました。
また、GitHubの使用イメージを掴みきれていない印象を受けましたので、こちらについては参考となるWebサイトや実務でイメージを掴んでもらう予定です。

チーム開発実践入門研修(LT)

チーム開発研修に入る前に、チーム開発をするうえで押さえておくべきキーワードの理解を深めるためにLTを実施しました。
進めるにあたり、次の書籍を参考にしました。 gihyo.jp

LTの題材とするキーワードは次の5つ。

• バージョン管理
• タスク管理/チケット管理
• 継続的インテグレーション
• 継続的デリバリー
• リグレッションテスト

LTの流れ

1. メンバー4人に担当キーワードを割り当てる
2. 30分で調査・発表資料作成を行う
3. 発表5分、質疑応答10分
4. プレイヤーチェンジ(担当キーワードを変更)
5. 10分休憩して次のキーワード調査スタート
6. 新卒メンバーが各キーワードをすべて担当(5周)したら終了

調査・資料作成・発表・質疑応答に時間をかけているため1日では終わらず、2日間に分けて実施しました。 新卒メンバーからは下記の反応がありました。

• Wikipediaで出てくるようなキーワードの概要までは掴めるが、業務で活用するイメージが湧かない
• 自分では理解したつもりだが、他の人からの質問に上手く答えられない

キーワードの理解度0から概要理解までは到達しやすいが、さらに理解を深める難しさを感じました。

LT形式にした狙いとして、短時間で自分の考えをまとめ、他の人に伝える経験をしてもらうということもあったため、上手くいかない実感を与えられたのは狙いどおりでした。
ここで湧いた疑問点をどんどん深掘りしていき、理解を深めてほしいところです。

チーム開発研修テーマ検討

次に、2ヵ月間で作成するWebアプリケーションのテーマ案検討を進めます。

テーマ検討の進め方

1. テーマ案書き出し用のスプレッドシートを用意
2. 30分テーマ出しの時間を設ける
3. テーマ案の共有
4. 新卒メンバーで投票し、上位5案に絞り込む(1人5票、重み付けなし)
5. 上位5案 + アドバイザー発案のテーマを合わせた全6案について、決選投票を実施。(1人5票、重み付けあり)

テーマ出しをする際には次の点を意識してもらいました。

• そのテーマが抱えてる問題は何か？
• その問題で困っている人は誰なのか？
• その問題を解決する難しさはどこにあるか？
• 解決したときのインパクトはどこにあるか？
• 解決後の拡張性はあるか？

テーマ決めは、ここまでで一番の盛り上がりを見せました。
こういう問題に対してこんなアプローチをして解決したら面白いんじゃないか？というアイデアが活発に出ていました。 今後実際の業務を行う際にも、現状抱えている問題を解決したら誰がどう嬉しいのかを意識しながら、システムの開発を行ってもらいたいなと感じました。

振り返り

この研修では毎朝の簡単な振り返りに加え、週次で振り返り(KPT方式)を実施します。
1週ごとに振り返ることで、短期間でのPDCAサイクルを回すことが目的です。

1. 今週の取り組みで継続したい点(Keep)と、問題点(Problem)を列挙(5分)
2. 内容共有(5分)
3. 問題点(Problem)に対する次の取り組み(Try)を全員で検討(15分)

初めの1週目は、慣れが必要ということもありTryに対する次のアクションは明確に決めませんでした。 今後設計/実装のフェーズに入った際には、TryからGitHubのissueを書き出し、翌日からissueへの取り組みを実施していく流れを作りたいと考えています。

3つのテーマ候補

トータル16個あったテーマ候補のうち、新卒メンバーが選んだ上位3つに絞り、それぞれの案を比較することにしました。3つのテーマ候補を次で紹介します。

1.会議室空き状況管理ツール(ゴースト会議バスターズ)

Webブラウザ上でリアルタイムに会議室の利用状況を確認し、予定登録状況を合わせて確認できるようにするツールです。

着目した問題点

• フリースペースなどの事前予約不要スペースの利用状況が分かりにくい
• 会議室について、打ち合わせの予定登録内容と、利用状況が異なる場合がある
  ※ ここでは、予定と利用状況が異なる状態をゴーストスケジュールと呼ぶことにします

このツールが与えるインパクト

社員全員が、フリースペースの空き状況確認をスムーズに行うことができるようになるだけでなく、 ゴーストスケジュールを発見することで、会議室の稼働率をあげることができます。

拡張性

• 会議室別の利用頻度の高い時間帯の可視化し、打ち合わせの時間帯を分散させる
• ゴーストスケジュール登録者を発見し、警告する(ルール遵守)
• ゴーストスケジュール検知時に、リアルタイムで空き状況をSlack通知する

実現方法のイメージ

2. 社内書籍管理ツール(Morio Library)

その名の通り、社内に多数ある書籍を一括管理するツールです。図書館にある検索・管理ツールをイメージするとわかりやすいでしょうか。

着目した問題点

• 社内に本は多数存在するが、点在していて探しづらい
• 本があっても、誰かが読んでいる途中かもしれず借りづらい

このツールが与えるインパクト

• 社内での書籍管理を一元化できる
• 社内での読書状況の共有や購買促進

拡張性

• 書籍購入リクエスト機能を追加する(需要の把握)
• 社内外の人気書籍ランキング機能(amazon技術書ランキングとの差分表示など)を追加
• 似たような分野の本を読んでいる人同士の交流を促す機能追加(ビブリオバトル開催機能)

実現方法のイメージ

3. GitHub issue管理ツール(issueまとまるくん)

社内の複数プロジェクトで使用されているGitHubのissueの管理をしやすくするツールです。

着目した問題点

• 複数のGitHubリポジトリに紐づいているissueの一括管理がしにくい
• 個人に着目した場合に、issueの粒度/重みがバラバラで生産性が測りにくい
• チーム/プロジェクト/フェーズ毎のissue割合が把握しにくく、チームビルディングに活かしにくい

このツールが与えるインパクト

• マネージャー陣が、プロジェクトやメンバーの評価しやすくなる。チームビルディングの際の参考にできる
• 各チームメンバー向けに、issueの種別(新規開発/運用/保守/バグ修正)を把握しながら優先順位を判断できる

拡張性

• エンジニア評価ツールとしての拡張
• 可視化後のデータ活用

実現方法のイメージ

部長プレゼン

新卒メンバーから、アドバイザーである王に対して上記テーマのプレゼンを行いました。

発表を終えて、王からの質問・意見は次のとおりです。

ゴースト会議バスターズ

• 実現するためにはカメラが必要になるが、いくらお金がかかる想定か？
• 仕様決めの難しさがある。たとえば、5分遅れで打ち合わせが開始する場合にどう判断する？
• カメラを使うのでデバイス制御が難しそう
• セキュリティ面での懸念が大きそう(会議室情報が漏洩するリスクの考慮は？)
• カメラ設置のために稟議を通す必要がありそう

Morio Library

• ユーザー/管理者の両方の視点が考慮されていてよい
• 初期導入コストが気になる。本一冊ずつにバーコードを付与し読み取る作業が大変そう
• 書籍の新規購入の際のフローはどうする予定？

issueまとまるくん

• ツールの運用ルールについて、すでに採用している方式をベースに検討するとよい
• マネージャー陣が評価の参考として使うのは難しそう。個人スキルの考慮が必要だったり、生産性の算出方法により左右されてしまう
• ラベルの活用法は、生産性だけでなくプロジェクトの方向性(エンハンスや保守)の可視化にも活かせると思う
• GitHubについて今は理解が足りないかもしれないが、実務で慣れていけるように頑張って！

テーマ比較検討

各案について、次の評価基準で比較しテーマを最終決定することに決まりました。

• システム仕様
• 実装期間
• 導入難易度
• 実用性

上記に基づき、新卒メンバーは各案を比較しました。

比較の結果、ゴースト会議バスターズは実現性の懸念点が大きく、2ヵ月間での完成イメージが見えない点が壁となりました。
また、issue管理ツールについてはissue数値化の仕様決め難易度が高い点が大きな課題となりました。

上記を踏まえ、新卒チーム開発研修のテーマは書籍管理ツール(Morio Library)に決定しました。

新卒メンバーは、これから要件定義/設計/実装/リリースの各フェーズを経て、ひとつのWebアプリケーションの完成を目指します。

最後に

始動編はここまでになります。キックオフ~テーマ決定だけでも多くの気づき・学びがあり、これからの新卒メンバーの成長が本当に楽しみです。
今後の記事でも、研修のリアルな温度感を皆さんに感じていただけるよう、内容をできるだけ細かくお伝えしていきたいと思います。 次回、8月中に「要件定義/設計編」を執筆予定ですので、ご期待ください！

こんにちは、クラウドSRE部の志甫谷（しほや）です！
IDCFクラウドの課金系システムをメインで担当しています。趣味はフットサル（プレー・観戦）です。

まえがき

これはIDCFに嵐を巻き起こす、夢と希望に溢れた 新卒エンジニア4人の果てしない挑戦の記録です！

※このまえがきは、【目指せ！Fの頂】*1のパロディです。

前回までのRookies Training Report 2019

2ヵ月間でWebアプリケーション完成を目指す4人の新卒メンバー。
作成するWebアプリケーションのテーマを決定し、要件定義/設計フェーズへと進んでいくのでした。 始動編の内容については、次の記事を参照してください。 blog.idcf.jp

要件定義フェーズ

新卒メンバーにとっては、要件とはなにか？というところからのスタート。
そこで、まずは目指すべきゴールを提示しました。
このフェーズで完成させるのは、要件定義書です。この中で満たさなければいけない項目を確認しました。

• このアプリケーションの概要説明(やること、やらないことを整理)
• 業務フローの列挙と整理(このアプリケーションを使用する場面とその流れの整理)
• 必要な画面の列挙、機能(非機能)要件の整理

業務フローの列挙と整理

業務フローの列挙をする目的は、必要な機能の見極めです。
Morio Libraryを使用する際の業務フローを整理することで、本当に必要な機能がわかります。

業務フローの列挙結果は次のとおりです。

• 書籍貸し出し
• 書籍返却
• 書籍返却期限切れ催促
• 書籍オファー(貸し出し予約)
• 書籍追加

業務フローの例として、書籍貸し出し業務の流れを示します。

1.据え置きタブレットでQRコードを読み取る
2. 貸出ページに遷移する
3. slackの表示名を入力して貸出確定ボタンを押下する
4. tokenが貸出者のslackに送信される
5. 貸出者がtokenを入力する
6. tokenが合っていた場合、貸出完了！

例で示したように、全ての業務に対して業務フローの具体的な流れを整理していきました。 整理を行うことで、次のフェーズで実施する設計、実装へとつなげていきます。

画面一覧の列挙

業務フロー整理後、必要な画面一覧を列挙しました。
それぞれの画面同士の関係性を明らかにすることを目的とし、
他の画面から遷移されない画面がある場合は不要であると判断できますし、
画面遷移の流れが不自然である場合に、画面構成を見直したりすることもできます。
画面一覧を列挙した後は、各画面の表示内容を書き出し、要件を洗い出していきました。

例として、検索結果表示ページの要件の整理内容を示します。

• タイトル(MorioLibrary)が表示できる
• タイトルを押下するとトップページに戻れる
• 検索窓に文字列を入力できる -文字数制限をかける
• 検索ボタン押下すると再度検索できる
• 本の検索結果を名前順で表示できる -並び替えができる（名前順、新着順、発売日、値段、貸出回数）
• 本の検索結果をフィルタリングして表示できる -貸出状況、ジャンル、本形態
• 本のタイトルを表示できる
• 本のタイトルの横に貸出状況を表示できる
• 貸し出し状況が貸し出し中の場合は、オファー申請ボタンを表示する
• 本のタイトルを押下すると詳細ページに遷移する
• ページ切り替えボタンをつける
• ページ番号を押下すると移動できる
• 本の検索結果を20件表示できる

要件定義フェーズはこのように進んでいき、部長との要件定義レビューの準備を進めました。
途中、考慮漏れがポロポロ出てきて、発表練習に時間を割けずに本番を迎えることになりました。

要件定義レビュー

テーマ検討以来となる、部長レビューがやってきました。
トピックとしては、要件定義書の内容確認です。(業務フロー、各画面の要件確認)

レビューでの宿題

要件定義レビューは、概ね問題なくクリアしました。
宿題として決めなければいけない項目について残りの時間で議論を続けました。

• 必須機能と、オプショナル機能の優先順位決め
• 返却/貸し出しページの分離についての検討
• 認証の方式をID/PASSを入力するページにするか、他の機能を採用するかの検討

部長の想定を超えるアウトプットであったため、 大きな修正点は指摘されませんでした。 これは大きな自信になったのではないでしょうか。
新卒メンバーは、続いて設計フェーズへと進んで行きます。

設計フェーズ

設計フェーズで実施するべきことは、画面遷移図・シーケンス図の作成とデータベース設計です。 このフェーズでは、実装を進めるうえで明らかにしておかなければいけない処理手順を書き出します。 また、各機能のシーケンス図を作成するうえで、必要となるデータベースのテーブル設計も明らかになるため、
シーケンス図作成後に、データベース設計を進めます。

設計フェーズ前半では、そもそもの設計の進め方がわかないという理由から、新卒メンバーはシーケンス図の作成やデータベース設計に苦戦してしまいました。 とっかかりとして、1つのシーケンスを書き出すところをチューターと一緒に行い、
イメージを掴んでもらいながら設計を進めていきました。

画面遷移図

シーケンス図

データベース設計

設計レビュー実施

3回目の部長レビューを実施。レビューも3回目ということでそろそろ慣れたかなと思いきや、
やはり準備前はバタバタ。発表者が明確に決まっていなかったり、発表資料表示がスムーズではなかったりと、
要件定義レビュー時の反省を生かせず、準備不足感が否めませんでした。

レビュー後の宿題

レビューの結果としては、大筋問題ないというコメントをいただけましたが、宿題も多く残りました。

• オファー機能は仕組み自体も複雑なので、実装も複雑化する懸念がある
• 実装期間を鑑みて、どこまでの完成を目指すのかを決めておかないと中途半端な状態で終わってしまう
• 初回のデータベース設計としては、想定より良いが、細かい点で気になる点がある。

サービス開発会議での進捗報告

設計フェーズまで完了したので、本部で行ってる会議でここまでの進捗報告を行いました。
要件定義フェーズでのアウトプットとして、要件定義書を提示し、
業務フローの洗い出し→必要な機能の洗い出し→機能ごとの要件洗い出しという流れは、
聞き手にとってもイメージしやすかったという手応えを感じました。

設計フェーズについても同様で、アウトプットとして、
画面遷移図、シーケンス図、データベース設計書を提示したことで、
聞き手にイメージが伝わったと思います。

また、激励の言葉もいただきましたので、次回の発表でも好評いただけるように頑張ります。

最後に

要件定義/設計編はここまでになります。
テーマ検討とは異なり、わからないことに直面することが多く、
苦しみながらも、もがきながら前進していく新卒メンバーが印象的でした。
壁を越える前、越えたときのモチベーションの上下であったり、
手応えを掴んでいく様子を間近で見られることがとても臨場感があり、
実装フェーズも非常に楽しみです。
次回、9月中に「実装編」を執筆予定ですので、ご期待ください！

こんにちは、クラウドSRE部の志甫谷（しほや）です！
IDCFクラウドの課金系システムをメインで担当しています。
趣味はフットサル（プレー・観戦）です。

まえがき

これはIDCFに嵐を巻き起こす、夢と希望に溢れた 新卒エンジニア4人の果てしない挑戦の記録です！
※このまえがきは、【目指せ！Fの頂】*1のパロディです。

前回までのRookies Training Report 2019

2ヵ月間でWebアプリケーション完成を目指す4人の新卒メンバー。
作成するWebアプリケーションの要件定義/設計が完了し、実装へ進みます。
始動編、要件定義/設計編については、次の記事を参照してください。
blog.idcf.jp

タスク整理

GitHubのissueで各自のタスクを管理していきます。
issueを作成する際のフォーマットは、以下の通りです。

• 概要
• クローズ条件
• 工数目安
• 完了期日

issueを作成した後に、担当者を決め、それぞれのタスクを進めていきます。

必須タスク一覧

各種ページの作成

• トップページ
• 書籍追加ページ(追加/確認/完了)
• 書籍詳細ページ
• token入力ページ
• 返却ページ(返却/完了)
• 貸出ページ(貸出/完了)
• 検索結果表示ページ

各種機能の作成

• token機能(発行/認証/削除)
• 書籍追加機能
• 書籍検索機能
• 貸出機能
• 返却機能

開発環境構築

実装を進めるにあたり、各自の実装内容を反映させ、
作成するアプリケーションの動作確認を行う開発環境を構築します。
構築手順については、テックリード篠田さんが作成し、
実際の構築は新卒メンバーが行いました。

1. VM作成
2. ファイアウォール設定
3. IPアドレス設定
4. Dockerインストール
5. GitHubからソースをgit clone
6. IntelliJを使うための設定

作成したVMに対してSSH接続が出来ない！
公開鍵の設定がうまくいかない！
という環境構築躓きあるあるに苦戦しながら、
4人は足並みをそろえて環境構築を進めます。

環境構築後は、必要なミドルウェアや
フレームワークを導入し使用出来る状態を作ります。

• PHP
• nginx
• MySQL
• Symfony

新卒メンバーにとっては、ミドルウェアって何ですか？
状態からのスタートですので、そもそも何がわからないのかがわからない。
迷いながら、モチベーションが下がっていきつつも、
なんとか諸々の設定を完了させることができました。

田栗さん「躓きながらも、突破口が見えた瞬間が一番楽しいですね。」

環境構築が終わった際のこの一言が印象的でした。

セキュリティ研修

実装フェーズの合間に、セキュリティ研修を実施しました。
以前から、セキュリティ要件の話題が出てきておりましたので、
社員が講師となって、機密性、完全性、可用性の話から始まり
インジェクションの解説をしてもらいました。

セキュリティについては全社研修でも行なっておりましたが、
わからない単語や概念が多数あったようで、ポカンとしている場面もありました。
しかし、わからない場合には積極的に質問が出ていました。

これをきっかけにしてセキュリティについての関心を持ってもらいたいところです。
攻撃方法がわかれば、守備方法もわかるというお話があったので、
チームに分かれて攻守を経験するのも良いのかなと思います。

実装開始

実装開始時点でも様々な壁にぶち当たります。

• namespace、classとは
• MVCモデルとは
• use、require、includeの使い分け
• アクセス修飾子の使い分け
• PDO？ステートメント？SQL？
• 動作確認の方法
• 相対パスと絶対パスの使い分け
• 引数の指定方法
• エンティティとは
• トランザクションとは
• 例外処理とは

独力で実装を進めることに難しさを感じていたため、
チューターとのペアプロで1つの機能を実装してイメージを掴んでもらうことにしました。
実装フェーズが進むに連れて、新卒メンバーは手応えを実感し始めます。
1つのエラーに躓き、独力で解決出来ない状態から、
独力で解決し、次のステップへ進んでいけるようになりました。
また、他の人の実装を一緒に進められるようになり、
お互いに助け合いながら、意見を言いながら進めていく姿が印象的でした。

大きな誤算と進路変更

Morio Libraryの実装を進める上で、大きな誤算がありました。
それは、社内のセキュリティ規定により、ユーザー情報を取得するSlack APIの使用許可が下りなかったことです。

これにより、次のようなインパクトが発生します。

• tokenをSlackのDMで通知ができなくなった
• 返却/貸出の通知ができなくなった

Slackではなくメール送信で代用しようとも試みましたが、
こちらもメールの誤送信リスクなどを理由に
十分な検証を経てからの使用が義務付けられました。

その結果、実装フェーズの残り期間では検証を完了させる目処が立たず、
token認証・通知周りの機能が全滅という状況になりました。

なりすましなどの対策としてtoken認証は必須であり、
その通知ができないという状況では、
社内アプリケーションとしてのリリースはできません。

そして、一番大きな影響としては、
この研修のゴールをアプリケーションのリリースではなく、
作成したアプリケーションのデモを行うところまでに
切り替えなければいけないということでした。

自分たちの実装したアプリケーションを、
リリースできずに実際のユーザーに利用してもらえないという状況は、
新卒メンバーに大きなショックを与えることになりました。

4度目の部長レビュー(実装デモ編)

本来は、4度目の部長レビューは、
リリース判定を行うために設定しておりました。
しかし状況が大きく変わったため、
作成したアプリケーションのデモを行い、
最終的なゴールを決めることを目的にしました。

これまでのテーマ決め/要件定義/設計と3回部長レビューを行ってきましたが、
今回の実装デモについても部長の期待値を上回っていたという評価をいただきました。
デモの見せ方に工夫が必要であったり、エラー処理周りについてのコメントはあったものの、
一通り形になったMorio Libraryをお見せすることはできたと思います。

4回のレビューを経て感じたことと、今後生かしてほしいこととしては、
部長のコメントは絶対ではないということです。
あくまで表に出てる情報を見てコメントしているので、それを必要以上に怖がる必要はありません。
仕様や実装内容、リソース、期限などを鑑みて改修するしないを判断するのは、
あくまで自分たちだという意識を持ってもらいたいです。
誰かにこう言われたからこうしました、という決断は正直して欲しくないですし、
こう言われたから僕たちはダメなんだと思う必要は全くないと思います。

〇〇だからこういう仕様・実装にしているという
自分たちの判断基準を大事にして欲しいです(意固地になれという意味ではありません)。
その上で、さまざまな意見を取り入れたりするなどの判断をして欲しいということです。

実装フェーズ完了時点でのMorio Libraryの紹介

最後に、これまでの全フェーズを経て出来上がったMorio Libraryの機能を一部分ご紹介します。

最後に

実装編はここまでになります。
次回、10月に「成果発表編」を執筆予定です。

リリース判定は通らなかったが、2ヵ月間で彼らは何を学んだのか、
全社向けの成果発表会でどんな反応があるのか、
そして、新卒メンバー自身の成長に繋がったのかどうか、
見所満載の最終回に、ご期待ください！

こんにちは、クラウドSREの森田です。

今回は、8/7にリリースしたRDBのリードレプリカ機能についてご紹介します。

リードレプリカ機能を利用するとシングル構成のRDBマシンまたは冗長構成のActiveノードをマスターとした、レプリケーションによるリードレプリカを作成することができ、読み込みと書き込みの負荷分散が可能になります！

リードレプリカ機能については次の方法で利用することができます。

1.RDBのトップページでリードレプリカを作成したいRDBを選択すると「基本設定」が表示されます。

2.「基本設定」から「リードレプリカ」クリックすると「リードレプリカ詳細画面」が表示されます。

3.「リードレプリカ詳細画面」で「リードレプリカを作成する」をクリックしリードレプリカに使用したいFQDN名の入力とマシンタイプの選択を行い「追加する」をクリックします。

4.確認画面が表示されますので「はい」をクリックするとリードレプリカの作成が開始されます。

5.リードレプリカ作成が完了するとステータスがRunningになりリードレプリカの「基本設定」からリードレプリカの情報を確認することができます。現時点ではリードレプリカについてはパラメーターグループの適用の機能を利用することができます。(※ボリュームはマスターのRDBのボリュームのサイズアップに合わせてサイズアップされます)

6.作成時に指定したFQDNでリードレプリカのMySQLにログインし SHOW SLAVE STATUSを実行するとSlave_IO_RunningとSlave_SQL_RunningがYesになりレプリケーションができていることが確認できます。

[morita@idcf-morita ~]$ mysql -utest -p -hidcf-rdb-slave.local.rdb.idcfcloud.net
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 298
Server version: 5.7.22-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: idcf-rdb-master.local.rdb.idcfcloud.net
                  Master_User: idcf_repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: bin_log.000002
          Read_Master_Log_Pos: 194
               Relay_Log_File: rdb-10e3bd25-297c-4e63-afd2-48be1b31391d-relay-bin.000004
                Relay_Log_Pos: 403
        Relay_Master_Log_File: bin_log.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 194
              Relay_Log_Space: 730
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: 
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 72b9a774-d9d7-11e9-8b45-1e0308003707:1-2
            Executed_Gtid_Set: 72b9a774-d9d7-11e9-8b45-1e0308003707:1-2
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:

7.実際にマスター側のRDBに書き込んだレコードをリードレプリカで読み込めるか確認してみましょう！マスターのMySQLにFQDNでログインし確認用のuserテーブルを作成しレコードを追加してみます。

[morita@idcf-morita ~]$ mysql -hidcf-rdb-master.local.rdb.idcfcloud.net -utest -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 70384
Server version: 5.7.22-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> create table test.user (id int, name varchar(10));
Query OK, 0 rows affected (0.01 sec)

MySQL [(none)]> insert into test.user (id, name)VALUES(1, "morita");
Query OK, 1 row affected (0.01 sec)

8.リードレプリカのFQDNでMySQLにログインしuserテーブルとレコードが追加されているか確認してみます。ちゃんと読み込めていますね！

[morita@idcf-morita ~]$ mysql -hidcf-rdb-slave.local.rdb.idcfcloud.net -utest -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 82083
Server version: 5.7.22-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> select * from test.user;
+------+--------+
| id   | name   |
+------+--------+
|    1 | morita |
+------+--------+
1 row in set (0.00 sec)

最後に

現在、IDCF クラウド RDBでは次の新機能の開発を進めておりますので今後もIDCF クラウド RDBの進化にご期待ください！

はじめまして、クラウド本部 クラウドインフラ部の松本です。

プライベートクラウド基盤の構築・運用と、IDCフロンティアが扱うクラウド内での移行に関する業務に携わっています。
今回私は、IDCFクラウドの管理基盤ソフトウェアであるvSphereと、 関連製品・ソリューションを展開するVMware社のイベント「VMworld 2019 US」 に参加してきましたので、その模様をレポートしたいと思います。
開催時期は2019年8月25日から8月29日まで、開催場所はアメリカ合衆国のサンフランシスコです。

www.vmworld.com

私は入社して以来、構築・運用・障害対応・バージョンアップなどでvSphereのvCenterやESXiに触れてきましたが、 ありとあらゆる場所で*1、 vCenterやESXiとそれに関連するVMware用語が（英語で）飛び交っている環境はとても新鮮でした。

参加の目的

イベントに参加した目的は、クラウド基盤をより良いものとしていくための技術動向のリサーチと、「世界のトレンドを体感する」ということです。
技術的に何ができるか、できるようになるかを知るだけでなく、 どのような技術になぜ関心が持たれているのかを知ることもまた大切なことだと思います。 そのような世界的なトレンドは、セッション数の分布でもわかりますし、 実際参加したセッションの熱量（質問数や、議論の白熱度合いなど）でもわかります。
後で記事になったものでは伝わりにくいこのような部分を体感できるのも、 実際にイベントに参加したからこそです。

VMworld とは

VMware社主催のイベントで、VMware製品の新バージョンやロードマップについての紹介、 ITの最新技術を扱った技術セッションなどで構成されます。
2004年以来毎年開催され、今年の会場はサンフランシスコ市のモスコーニ・センターでした。 近年は（アメリカでは）ラスベガス開催が主でしたが、今年は原点回帰でサンフランシスコが会場になったようです。

VMworldは毎年テーマが決まっていて、今年は Make Your Markでした。

General Session

8月26日・27日の二日間、それぞれVMware社CEO：パット・ゲルシンガーとCTO：レイ・オファレルが製品のロードマップや事例を紹介するセッションで、参加者の大多数が一堂に会する数少ない場*2でもあります。

VMworld 2019 US | General Sessions | VMware

General Sessionはその性質上、技術に関する詳細な話はあまりされない傾向にあります。ただ、CEOやCTOがどのような意志と理念で何に注力していくつもりなのかが強くあらわれる場なので、必聴のセッションです。この場でこそ発表されるサプライズもあります。今回は8月27日のセッションで、グレッグ・ラベンダーが新たなCTOに就任するという発表がありました。

General Sessionの概要はリンク先の記事がわかりやすいので、ご参照ください。
ASCII.jp：「VMware Tanzu」発表、“エンタープライズKubernetes”加速を支援 (1/2)

注目の技術・ソリューション

今回のVMworldは、何かひとつ目新しい技術が発表されるというよりも、既存の製品とVMware社が買収した製品とを組み合わせることで成立するクラウドのポートフォリオ全体を推していた印象です。
クラウドサービスとその技術がかなりの程度浸透したからこそ、レガシーなシステムのクラウド化やモダナイズ（コンテナ化）、そしてクラウド間の移行技術に関心とニーズが集まっていて、それに応える形でVMware社も包括的な解決策と道筋を提示しているのでしょう。
その中でも目を引いた注目の技術は次の2つです。

• VMware Tanzu
• NSX-T

やはり今回の目玉は「Tanzu」と命名された、vSphere上でのKubernetes（k8s）を統合管理するソリューションだと感じました。
ただ単にvSphere上でコンテナが動くという話ではなく、ESXiというVMware社の提供するハイパーバイザーOS自体にk8sを実行＆管理する機構を組み込み、ESXiの管理サーバーであるvCenter上で、コンテナが仮想マシンと同様に管理可能になる構想です。
アプライアンスや連携のソリューションではなく、vSphereの核であるESXi自体に大きな変更を加えることでコンテナ技術に対応しようというところに、VMware社の本気が伺えます。
Tanzuは製品名ではなくブランド名とのことで、vSphereのコンテナ対応とマルチクラウド環境の統合管理に関わるさまざまな製品で構成されるようです。

NSX-Tは以前から存在し、既に多く利用もされているVMwareのネットワーク仮想化ソフトウェアですが、今までに備わっていなかった機能が多数追加されフルスタック化するということで、非常に注目されていました。
今まで導入しようとしても必要な機能が足りないために見送っていた人も、いよいよネットワークの仮想化を考えようかな、という時期なのだと思います。実際に製品を体験できるハンズオンラボのTOP10コンテンツの1位はNSX-Tで、関心の高さが伺えます。

所感

仮想化やコンテナ化がもはや当然であり、前提の世界であるということが改めて体感できた貴重な機会でした。
入門用セッションを除くと、どの場所、どのセッションでもコンテナ化とは？やKubernetesとは？というような導入や注釈を見かけることがなく、用途や要件でクラウドを使い分けるマルチクラウドの世界を前提としたソリューションや技術が多く展示されていました。セッション数は全体で700ですが、そのうちの過半数の474がHybrid Cloud,Modern Apps,Multi-Cloudをテーマにしていたようです。

また、世界各国のクラウドベンダーが抱える悩みや要望が、私たちが抱えるものと非常に近しい、もしくは同じであると知ることができたことも収穫だったと思います。
誰もがレガシーなシステムの移行に苦しんでいたり、コストに見合う製品をなかなか見つけられなかったり…課題が似通っているからこそ、解決することができればそれはきっとワールドワイドにも通じるものになるでしょう。
そのような、根本的な部分での課題解決ができるエンジニアになりたいなと、決意を新たにしました。

今後もIDCフロンティアは様々なイベントに参加し、このブログでレポート記事を投稿したいと思いますので、ご期待ください！

こんにちは、クラウドSRE部の志甫谷（しほや）です！
IDCFクラウドの課金系システムをメインで担当しています。
趣味はフットサル（プレー・観戦）です。

まえがき

これはIDCFに嵐を巻き起こす、夢と希望に溢れた 新卒エンジニア4人の果てしない挑戦の記録です！
※このまえがきは、【目指せ！Fの頂】*1のパロディです。

前回までのRookies Training Report 2019

2ヵ月間でWebアプリケーション完成を目指す4人の新卒メンバー。
書籍管理ツール「Morio Library」の実装が完了したかに見えましたが、
セキュリティ要件を満たせずにリリースは叶いませんでした。
新卒メンバー4人は、気持ちを切り替え、全社成果発表会の準備を進めていました。
始動編、要件提示・設計編、実装編については、次の記事を参照してください。
blog.idcf.jpblog.idcf.jpblog.idcf.jp

全社成果発表会

2ヵ月半、新卒メンバーが大半の時間を過ごしてきた場所で、全社成果発表会を実施しました。
彼らが辿ってきたこれまでの軌跡(テーマ決め、要件定義、設計、実装)の説明と、
この研修が彼らにどのような成長をもたらしたのかを振り返りました。

成果発表会実施にあたり、新卒チーム開発研修の連絡用に使用していたSlackチャンネルや
全社向けの連絡Slackチャンネルにて事前告知を行いました。
結果として、会場に足を運んでいただいた方々と大阪からテレビ会議で参加いただいた方々を合わせると、 総勢20名以上の社員の方々に新卒メンバーの成果発表会に参加してもらえました。

成果発表会では、想定よりも多くの参加者がいたからなのか新卒メンバーの緊張感が伝わってきました。
4人の新卒メンバーは、リレー形式でテーマ決め、要件定義と設計、実装、デモを分担して発表を行いました。
各フェーズの発表後、4人が研修の前後で自分が成長した点を発表し、成果発表は無事に終了しました。

新卒メンバーの成長(自己評価)

新卒チーム開発研修の目的は、チーム開発の経験を積むことでした。
今、研修が終わるタイミングで彼らに自分自身で感じた成長を書き出してもらいました。
青線が研修前の自己評価、赤線が研修後の自己評価です。
要素としては、これまでの各開発フェーズに関連する要素それぞれについて、 最小値0から最大値100で自己評価を行いました。

小野里さんに関しては、要件定義や設計など学生時代には取り組んだことがなかった開発フェーズを経験したことで
それらの要素についての成長を実感していたようです。
また、日次でその日やることや昨日やったこと、懸念点を確認する(日例)習慣が、短期間でのタスク管理の習慣を
身につける良いきっかけになったようでした。
ここにはない要素ではありますが、チーム全体の状況を冷静に見つめられたり、チームメンバーの意見を取り入れる柔軟性もありました。

特筆すべき点は、解決力です。前後での数値の違いはそこまでないものの、 庄司さんは、チーム開発を進める中で、自分で解決するという意識が強過ぎたという反省をしていました。
これから配属先での業務を進めるうえで、責任感を感じすぎて、タスクを抱え込んだり、
相談のタイミングを見失わないように気をつけたいところです。
元々好きだと言っていた設計周りも、開発フェーズを経験するうえでイメージを掴めていました。

田栗さんは実装フェーズでぐんと成長した一人。元々、理解力が他のメンバーに追いついていないという自覚があっただけに、 なんとかみんなに食らいつこうと、わからないことは100%理解するまで、質問を繰り返していた姿勢が印象的でした。
疑問点をそのままにせずひとつずつ地道に潰していった結果、実装フェーズ3週目には一人でエラー内容を理解し、
実装を一人で進めていけるまでに成長しました。

4人の中で、配属先のタスクを早くも与えられ、この新卒チーム開発研修のタスクと並行して、 タイムマネジメントが一番上手だったのが北條さんでした。彼も、実装フェーズでは、苦しみながらも、 メキメキと成長していった姿が印象的でした。自己評価で協調性の数値を高くしていることについても、 4人でのチーム開発を進める際に、他の3人の意見を上手に取り入れていた点が印象的でした。

成果発表会参加者からの意見

成果発表後に、参加者に向けてSlackを通して、アンケートの記入を依頼しました。
いくつか回答をご紹介したいと思います。

まず、作成した書籍管理ツール「Morio Library」を使用したいと答えた方の割合は85%でした。 さらに、新卒チーム開発研修を来年も継続した方が良いと答えた方の割合も85%でした。

継続すべきではないと答えた方の理由としては、チューターにかかる稼働負担が高いからとのことでした。 確かに、チューターはこの2ヵ月半ほぼ付きっきりの状態でした。チューターの負荷を減らす点は今後の課題だと思います。

また、他に欲しいと思うWebツールはありますか？という質問に対しては、 トイレの空き状況を知りたいという意見や、フリーアドレス制になった場合に、
誰がどこにいるかを把握するツールが欲しいとの意見をいただきました。

最後に、新卒メンバーへのアドバイスとして、 コーディング以外で気になった・ハマった・勉強の必要性を感じたことを聞きたいとの意見がありました。 各人の個性・強みを知る材料になるのかなと思います。

所属部署向けの成果発表会

全社成果発表会と同週に、新卒メンバーが所属する本部向けにも成果発表会を実施しました。 内容自体は、全社成果発表会の内容の短縮版ですので、割愛します。

評判としては、概ね好評で、この取り組み自体を全社にもっと展開すべきだという話になり、
後日、経営層へ向けての成果発表会を行うことになり、予想外に大きな広がりを見せる結果となりました。
この2ヵ月半の取り組み自体に大きな意味があったと言えるのではないでしょうか。

モチベーショングラフ

新卒チーム開発研修中に行なっていた取り組みを1つご紹介します。
それは、モチベーショングラフです。
今回の新卒チーム開発研修では、週次での振り返り(KPT形式で実施)と、
このモチベーショングラフを書いてもらいました。
各営業日での自分のモチベーションの高さを-100から100の間で記入し、
折れ線グラフで表現するというものです。

このモチベーショングラフは、
新卒メンバーのメンタルヘルスケアを目的として始めたのですが、
次第に新卒メンバー同士のフォロー体制を強化する材料として活用されつつありました。
たとえば、実装フェーズは、全体的にモチベーションが低下することがちらほらありました。
エラーにハマったり、実装の見通しがつかなくなったり、度々問題に直面することがあったのですが、
その都度、4人は全員で団結してそれらの問題を解決し、乗り越えてきました。
マネージャー向けの用途以外に、チームメンバーが各々の状況を把握するのにとても有効だと感じましたね。

チューターの成長

新卒チーム開発研修の目的は、新卒メンバーだけではなくチューター向けに
プロジェクトを主導する経験値を積むという目的もありました。

今回、私はPMとしてこのプロジェクトに参加し、
アドバイザと新卒メンバーとの板挟みに悩まされたり、
期日を意識して、スケジュールを守る難しさを感じたり、
チーム全体で進んでいく達成感を得ることができました。

また、テックリードとしてこのプロジェクトに参加した篠田さんは、
新卒メンバーの成長を促すためのプロジェクトの関わり具合に難しさを感じていたり、
工数見積もりの精度についての課題を感じたりしていました。

チューターにとっても実りある2ヵ月半だったと言えます。

最後に

成果報告編はここまでになります。
今回の研修を通して、新卒メンバーの成長を多くの場面で感じることができました。
また、来年以降も、チーム開発研修の実施に向けての動きがありそうです。
そのときは、今年の新卒メンバーがチューター役や、相談役として再び活躍してもらえると、
また別の視点からの成長に繋がるのではないかと思います。
社内的にここまで腰を据えてじっくりと新卒チーム開発研修を実施したことが初めてだったということで
この取り組みが来年以降も改良を重ねて、続いていくことを切に願っております。

新卒チーム開発研修は終わりますが、新卒メンバーの活躍の場はここから始まります。 新卒メンバーのこれからの活躍にご期待ください！

はじめまして。クラウドSRE部の篠田です。IDCFクラウドDNSを担当しています。

10/15にIDCFクラウドDNSに新しいレコードタイプであるALIASレコードとCAAレコードをリリースしましたので、その紹介をさせてください。

新しいレコードタイプの紹介

ALIASレコード

ALIASレコードは、値に指定したFQDNを名前解決して得られるIPアドレスが直接返却されるレコードです。

たとえば、以下のようなレコードが存在するとします。

www.example.com.     IN   A   93.184.216.34

alias.idcfcloud.com.     IN   ALIAS   www.example.com.

このとき、alias.idcfcloud.comは93.184.216.34を返します。

$ dig alias.idcfcloud.com +shor
93.184.216.34

ドメインを別のドメインへ転送できるため、ALIASレコードの動作はCNAMEレコードと似ています。大きく違うのは、CNAMEではできなかったZone Apexの転送が可能ということです。

しかし、Zone Apexのドメイン転送はフィッシング詐欺などに悪用されてしまう可能性が比較的高いです。そのため、ALIASレコードの値には自身の所有するホストのFQDNしか指定することができないような制約を設けました。現在はILBとCDNのFQDNのみ指定することができます。

CAAレコード

CAAレコードは、SSLサーバ証明書の発行を許可する認証局を指定するレコードです。

たとえば、以下のようなCAAレコードを作成することで、www.example.comのLet's Encryptの証明書・ワイルドカード証明書の発行が許可されます。同時に、Let's Encrypt以外の認証局の証明書の発行は拒否されます。証明書発行が拒否された場合、それがtest@idcf.com宛てにメール通知されます。

www.example.com.     IN   CAA   0 issue "letsencrypt.org"
www.example.com.     IN   CAA   0 issuewild "letsencrypt.org"
www.example.com.     IN   CAA   0 iodef "mailto:test@idcf.com"

2019年10月現在、CAAレコードが存在しなくてもSSLサーバー証明書の発行は可能です。そのため、証明書を発行するという用途ではCAAレコードを作成するということは少ないと思います。

CAAレコードが効果を発揮するのは、証明書の発行を拒否できるという点です。これにより、第三者に勝手に証明書を発行されるということを防ぐことができます。上述のCAAレコードではLet's Encrypt以外の認証局からの証明書の発行を拒否できますが、すべての証明書発行を拒否する場合は以下のようにCAAレコードを作成します。

www.example.com.     IN   CAA   0 issue ";"
www.example.com.     IN   CAA   0 issuewild ";"
www.example.com.     IN   CAA   0 iodef "mailto:test@idcf.com"

新しいレコードタイプの作成方法

管理画面

DNSの管理画面にアクセスします。

レコードを作成するゾーンを選択します。

レコード登録画面を開きます。

レコード登録画面のタイプの欄にALIAS, CAAのボタンが追加されています。こちらをクリックすることでそれぞれの登録フォームを表示することができます。画面上には各設定値に指定できる値の制約条件を記載していますので、参考にしてください。

API

APIからの作成も可能です。
以下はidcfcloud-cliを利用して作成したものです。CLIは簡単でいいですね。
CAAの値にはダブルクオーテーションが必要なので、JSONで記述する場合にエスケープが必要です。

$ idcfcloud dns create_record XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX '{"name":"alias.example.com","type":"ALIAS","content":"alias.public.ilb.jp-west.idcfcloud.net","ttl":"3600"}'
{
  "status": 200,
  "message": "",
  "data": {
    "uuid": "YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY",
    "name": "alias.example.com",
    "type": "ALIAS",
    "content": "alias.public.ilb.jp-west.idcfcloud.net",
    "ttl": 3600,
    "description": "",
    "created_at": "2019-10-16T19:08:17+09:00",
    "updated_at": "2019-10-16T19:08:17+09:00"
  }
}
$ idcfcloud dns create_record XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX '{"name":"caa.example.com","type":"CAA","content":"0 issue \"ca.example.net\"","ttl":"3600"}'
{
  "status": 200,
  "message": "",
  "data": {
    "uuid": "ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ",
    "name": "caa.example.com",
    "type": "CAA",
    "content": "0 issue \"ca.example.net\"",
    "ttl": 3600,
    "description": "",
    "created_at": "2019-10-16T19:11:17+09:00",
    "updated_at": "2019-10-16T19:11:17+09:00"
  }
}

※一部情報はマスクしています

最後に

今回の新規レコードタイプ追加ですが、かなり前から計画していたものをやっとリリースできたというものでした。特にALIASレコードの方はお客さまからのご要望の声も多く、ずっと提供したいと思っていた…と聞いています。

はい、実は私はIDCFクラウドDNSを担当するようになってまだ１年未満の新入りなのです。そんな私が今回のプロジェクトをメインで任されたということで、すごく大きな想いを背負った仕事だったのですが、責任感を持って取り組むことができたと達成感を感じています。

また、同時期に私は別件にも携わっていたのですが、こちらもこちらで私にとっては初めての経験でかなり苦労してしまい、そんな大変なプロジェクトを掛け持ちでやる切ることができたことに安堵しています。

DNSはWebシステムを支える大黒柱。そんな緊張感と責任感を持って、引き続きお客さまに満足していただけるサービスを提供していきたいと思っています。