FJCT Tech blog

富士通クラウドテクノロジーズ公式エンジニアブログです

富士通クラウドテクノロジーズ

FJCT/Tech blog

ニフクラウンジの紹介

f:id:yaaamaaaguuu:20190517162548p:plain
nifclounge logo

ニフクラ を提供する 富士通クラウドテクノロジーズ は、ニフクラウンジという取り組みを実施しており、この記事ではニフクラウンジの紹介と、利用フォームへの案内などをいたします。

ニフクラウンジとは

ニフクラウンジとは、ITエンジニアやクリエイターが技術力向上などを目的として開催する勉強会を対象に、当社のセミナールームを無償で貸し出す取り組みです。

ご利用していただく際は、こちらのフォームより申し込みをお願いいたします。

会場と設備について

ニフクラウンジの会場は最小1部屋30人程度から、最大4部屋をつなげることにより最大200人を収容することが可能です。 以下の写真は4部屋をつなげた状態となります。

f:id:yaaamaaaguuu:20190621131455p:plain
ニフクラウンジ 会場

会場受付では、イベントの案内を掲示する事が可能なので、ご利用の際には、勉強会を案内する印刷物を用意してください。

各部屋にはワイヤレスのマイクと、スライドを投影するプロジェクタがあります。プロジェクタはHDMIでのみ利用可能ですが、HDMIを変換するアダプタを持ち込んでいただくことで他の端子も利用することが可能です。

また勉強会をオンラインで配信するための機材はございません。オンライン配信を行いたい場合は機材を持ち込んでいただく必要があります。

会場では飲食などが可能なので、ビアバッシュ形式の勉強会や、懇親会を開催していただくことが可能となります。 ケータリングなどの主催者とは別の方が飲食物を搬入する方式も受付可能なので、利用の申込み後にご相談ください。

最寄り駅からニフクラウンジまでのまとめ

最寄り駅から弊社までの各ルートは以下のブログに記載されています。

勉強会を開催する際の注意点

ビルの都合上、正面エントランスは19:30に閉まります。それ以降の時間の入退室は通用口からとなりますのでご注意ください。

詳細について

こちらに本ブログの内容を含め詳細を記載しておりますので、ご確認ください。

www.slideshare.net

最後に

ニフクラウンジは富士通クラウドテクノロジーズが提供する、技術力向上などを目的として開催する勉強会を応援するための取り組みです。 ご利用の際は こちらのフォーム より申し込みをお願いいたします。

Engineer Task Force 2018 レポート

富士通クラウドテクノロジーズ AdventCalendar 2018 25日目です。

qiita.com

皆さまこんにちは!Merry Christmas!25日間お疲れさまでした。

最終日は、Engineer Task Force 委員長の織田がお送りします。

とみたさんの後にお送りするのはプレッシャーが半端ないです。

Engineer Task Force については、昨年の Advent Calendar の記事をご覧ください。

tech.fjct.fujitsu.com

 

この記事では、 Engineer Task Force が取り組んだ施策の中から、いくつかご紹介差し上げる形で締めくくりたいと思います。

 

エンジニアのビジョン形成に向けて

FJCT はクラウドサービスデータ・AIソリューションサービスといったサービスを内製によって提供している事業会社になります。
自らサービスを構築し世の中にバリューを提供する上で、我々は何をビジョンとし、どのようなスタンスで、何を重要視しながら働いていくのか、これを明確にする必要性があります。

まずはエンジニアのロールモデルとスキルマップでベースを構築

そのために、まずエンジニアスペシャリストのキャリアを確実なものにするため、

  • エンジニアスペシャリストの定義付け
  • クラウドエンジニア、データサイエンティストのスキルマップの定義付け
  • スペシャリスト幹部社員に求められる要件の定義

など "How" の部分を進めていきました。

12月現在でもまだ微調整を行っており、人事制度への足掛かりや調整の段階ではありますが、

  • FJCT がカバーする技術領域
  • 評価の対象となる技術
  • 評価軸や要求されるスキルの見直し体制
  • 一般クラスから幹部クラスまでに必要となるスキルとカバー範囲の定義
  • 定量化するべき評価軸と定性を維持する評価軸の議論

などが、毎週議論され、経営・幹部・人事などを中心に制度化に向けて進んでいます。

FJCT のエンジニアが実現するビジョンをエンジニアたちが掲げる

そして、最も重要な "What" の部分である、FJCT の技術ビジョン、行動哲学、行動規範を築いているのが今現在となります。

これらをどのように進めているのかは以下の通りです。

  • Engineer Task Force x 人事のワーキンググループで骨子と大方針を策定
  • 社長との会議において、提言と承認
  • 技術系幹部との事前相談での調整
  • ワーキンググループでたたき台を作成( gitlab の issue )

今後の予定として、

  • Slack でエンジニア全員が参加するチャンネルに issue を共有して叩きあげる
  • ワーキンググループで完成形を作成して経営に報告

を控えています。

これにより、我々は何を目指し、どのように振る舞い、実現に向けて何を用いて、それがどのようなプロセスで評価され、そのためにどんな課題を解決するのかが明文化される計画です。

 

続きを読む

モダンな開発・運用環境を導入するために奮闘した(している)話 2018

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の23日目の記事です。 体調を崩してしまって記事の仕上げが大幅に遅れてしまいました。申し訳ありません。

22日目は @heriet さんの「 KnativeのコンポーネントとCRD 」という記事でした。 2019年に向けて抑えておきたい技術Knativeの概要を抑えた記事でしたね。

はじめに

仕事では、 ニフクラ における企画・設計・開発・運営を担当している @ysaotome です。 富士通クラウドテクノロジーズ Advent Calendar 2018に参加するにあたり、一昨年から継続している「モダンな開発・運用環境を導入するために奮闘した(している)話 2nd」がその後どうなったのか?という事、で、2018年現在の状況を書きたいとおもいます。

f:id:ysaotome:20190103214951p:plain

※昨年投稿した「モダンな開発・運用環境を導入するために奮闘した(している)話 2nd」を読まれてない方は、昨年記事もご参照ください。

続きを読む

KnativeのコンポーネントとCRD

この記事は富士通クラウドテクノロジーズ Advent Calendar 2018の22日目です。 昨日は @ntoofu さんの「続・IaaS基盤をテストする環境を作る話」でした。私の場合はいい感じに使いやすいクラウド上で自動テストする環境を作るケースが多く、クラウドの機能等を使って楽ができるのですが、そのクラウド基盤向けの自動テストとなると独自にいろいろ作りこんだり、試行錯誤する場面がより多そうですね…!

はじめに

ニフクラのエンジニアリングパーツの開発・運用を担当している id:heriet です。 この記事では、Knativeを構成するコンポーネント群と、それらを構成するCRDについて紹介したいと思います。

ニフクラではエンジニアリングパーツという形でニフクラ上のシステムに組み込みやすいパーツを提供しています。たとえば、ニフクラ RDBはマネージドなDBサービスで、 ニフクラ スクリプト はサーバーレスを実現するサービスです。エンジニアリングパーツのようなサービスを実現するためには数多くの技術を取り入れる必要があるのですが、Knativeはその中で注目している技術のうちの一つです。

続きを読む

続・IaaS基盤をテストする環境を作る話

この記事は富士通クラウドテクノロジーズ Advent Calendar 2018 21日目です。

20日目は @egoa56さんの サーバログイン時にエモい画像を出してAORI駆動開発してみた話でした。個人的な思い出話で恐縮ですが、学生の頃、管理者権限を持っていた研究室の共用サーバーで、学友が利用中の疑似端末のデバイスファイルに「進捗どうですか」と書き込んでいたずらしていたこと(例: echo "進捗どうですか" > /dev/pts/XX)を思い出しました。この話を参考にすれば、より強いAORI力を得られていたと思います。(※いたずらは節度をわきまえましょう)

はじめに

本日は @ntoofu から、 「続・IaaS基盤をテストする環境を作る話」と題して、 仮想インフラ周りのテストにまつわる話をしたいと思います。 (「続」とあるように、今日の話は去年のAdvent Calendarに投稿した IaaS基盤をテストする環境を作る話 の続報も兼ねています。)

まずは、去年から取り組んでいるIaaS基盤運用にContinuous Integration (CI)の考え方を 導入しようという動きについて簡単に説明します。

現在の私の業務は、去年までに続いて今年もニフクラという IaaS型のクラウドサービスの仮想化基盤の面倒を見るのが中心です。 VMware製品を仮想化基盤に採用しているため、vCenter ServerやNSX等を扱うことが多く、 加えて基盤運用の中で必要なサーバーにはOSS製品なども利用しており (例えば、ログの保持にElasticsearchを用いるなど)、 そうした多種多様のサーバーを運用しています。

管理する台数も多いため、それらの運用は随所で自動化がなされています。 新たに手順を自動化したり、自動化のスクリプト自体を修正したりと言ったことも日常的に 行っており、比較的コーディングを行う機会は多い業務になっています。 (10日目の記事である Operation as a code 実現に向けた運用統合ライブラリの作成活動について にて紹介している取り組みなどは、スクリプトの改善の良い例です。) また、例えばスケーラビリティの問題などで、運用中にサーバーの設定を変更したり、 トラブルの再発防止のために監視項目を追加したいということもしばしば発生します。

こうした都合により、自動化スクリプトの変更や、IaaS基盤運用システムに対する変更は 日常的に必要になっています。その一方で、それらの変更にミスがあった場合、 サービス障害に結びつくことも珍しくないため、その品質についても担保しなければなりません。

しかしながら、闇雲に確認作業やレビューを増やすといった古典的なアプローチでは、 運用システムに対する変更を加えることへの負担が大きくなってしまい、

  • 変更が大きくなることで、トラブルを生むリスクが増す
  • 変更を加えられる間隔が長くなるため、改善を図ってから恩恵を受けるまでが遅くなる
  • 変更に対する工数の多さがモチベーションを下げ、細かな問題は放置されやすくなる

といったリスクがあると考えています。

そこで、 より迅速に、それでいてより安全に、システムの設定や運用自動化の改善を行いたい という思いから、CIの考え方を導入したいと画策し、去年より活動しています。 CIは、ビルド・テストを自動化することで、本流となるソースコード(一般的にmasterブランチのもの) に対する修正(変更のマージ)を、日常的に実施できるようにすることであり、 迅速かつ安全にプロダクトを改善・エンハンスするという、 まさに求めていたメリットを得られることが期待できます。

IaaS基盤のテスト環境

しかし、CIの考えを取り入れるためには、前提となる「自動ビルド・自動テスト」を実現せねばなりませんが、 実際にはテスト環境を整備する部分に大きな課題がありました。 その解決のために、Nested hypervisorを活用し、テスト環境をオンデマンドに作成できるようにしました。 (一部、去年の内容と変わっていますが、問題があってやり方を少し変えていたりするためです。)

テスト環境として元々用いられていた環境は、多くの開発者が利用している環境であり、どうしても クリーンな状態が保ちづらい状況にありました。また、hypervisor自体がテスト対象になることも あるため、環境の数に応じて物理サーバーが必要になるので環境の数自体も制約が大きい状態でした。 したがって、自動ビルドが安定して動くとも考えにくい上、自動テストを並列で実施したりすることが 出来るほどの環境の数もないような状況でした。

そこで、以下のようなアプローチでこの問題を解決しています。

Nested hypervisor

f:id:tofu_cider:20181221080035p:plain
Nested hypervisor

通常hypervisorは物理サーバーにインストールし、その上で仮想マシン(VM)を実行できるようにしますが、 VMの上にhypervisorもインストールすることは可能で、Nested hypervisorと呼ばれています。 これを利用することで、テスト環境に必要になるESXi(VMware基盤におけるhypervisor)をVMとして 柔軟に扱うことが出来ます。

Linked clone

Nested hypervisorによりhypervisorをVMとして扱えるため、 vCenter serverのような管理サーバーや後述の踏み台サーバーなどのテスト環境に必要な他のコンポーネントVMとして用意しておけば、それらVM群をまるごとClone(コピー)することで 環境をいくつでも複製できることになります。 したがって、「種」になるようなVM群を一度用意しておけば、 以降同じような環境を簡単に作成可能になります。

しかし、単純にこれを行うと、環境を増やす度に全VMのデータをコピーする必要があり、 ストレージ容量を大量に消費する上、コピー自体に時間がかかってしまいます。

そこで、Linked cloneと呼ばれる方式を利用します。Linked cloneは端的に言えばCopy on Write方式の cloneであり、実際に書き込みが発生して差分が生まれるまではCloneしてもほとんど容量を消費しません。

ネットワークの隔離

また、Cloneする方法はストレージ以外にも問題があります。 各VMIPアドレスや、Nested hypervisor上のVMMACアドレスは変化しないため、 Clone前後のVMたちが同じL2ネットワークセグメントに属することが出来ません。

f:id:tofu_cider:20181221080214p:plain
ネットワーク隔離

そこで、VM群を全て同じ物理サーバー上に配置する代わりに、 uplinkを割り当てない仮想スイッチを環境ごとに作成してVM群をそこに接続することで、 他の環境に影響を与えないネットワークを利用できます。

踏み台サーバー

単純に専用仮想スイッチだけで完結しては環境へのアクセスの手段がないため、 1台だけ環境の外と中の間を橋渡しできる踏み台サーバーを用意し、それを利用することにします。

f:id:tofu_cider:20181221080306p:plain
踏み台サーバー

踏み台サーバー上では、環境内からインターネットのリソースにアクセスするためのHTTP proxyや、 環境内で使うためのDNSサーバーを稼働させています。

また、テストやビルドのためのプログラムは環境内で実行する必要があり、それを容易に行えるように するために、Docker APIの受け口をTCPソケットで公開したDocker hostを環境内に用意しておき、 踏み台にはDNATの設定をしておくことで環境外から環境内のDocker host上でコンテナを実行できるように しています。同時に、踏み台サーバーでNFSサーバーを稼働し、環境内Docker hostと環境外の作業サーバーで マウントすることで、コンテナと間接的にファイルシステムの一部を共有できるようにしています。

ストレージ

f:id:tofu_cider:20181221080357p:plain
FreeNAS VMを利用

Nested hypervisor上で可動させるVMの利用するストレージ(データストア)は、 VMとして環境ごとに構築したFreeNASを利用することで、環境の破棄に応じて 全てまとめて削除できるようにしています。

一時期vSANも試していたのですが、冗長化のため2つのNested hypervisorで 書き込みが発生しても、最終的に同じ物理ストレージへの書き込みとなるため、 無駄が多いことが予想され、実際にそのせいだったかは定かではありませんが、 私が検証した環境ではFreeNASの領域をiSCSIマウントするほうが高速でした。

自動ビルド

環境が整備できたところで、まずは自動ビルドをすることにしました。 ここでビルドした後の環境を、ビルド済み環境として流用することで、 各種のテストを行うための環境として活用が可能になることが 期待できたため、優先的に取り組みました。

特に説明なく「ビルド」と表現しましたが、インフラ自体に対するビルドとはいわゆる構築のこと であると考えており、IaaS基盤運用システムを対象にした自動ビルドとはすなわち、 先に説明したテスト環境にIaaS基盤運用のシステムを自動構築することに他なりません。

既に、基盤運用に用いる各種サーバーの構築は Ansible によって自動化されていたため、 テスト環境内にてこのAnsibleを実行することにより、自動ビルドは実現することができました。 実際には、テスト環境用のパラメータを用意したりテスト環境固有の細かな問題を潰す必要は 出てくることがあり、サーバーの種類が多かったこともあってそれなりに手間はかかりましたが、 特別な工夫はあまりありませんでした。

f:id:tofu_cider:20181221082059p:plain
ビルド後の環境の流用

また、ビルド後には、テスト環境の作成のために種になるVM群を軒並みLinked cloneするのと同様に、 テスト環境のVM群を軒並みFull clone(実際に全てコピーする)することにしています。 これは、Full clone後のVM群をテスト環境作成の種として扱うことで、ビルド後の状態のテスト環境を 直ちに用意できるようになるためです。

自動テスト

基盤運用に必要なサーバーが構築済みのテスト環境が容易に作成できるようになったため、 これに基づいて、実際にシステムの正常性を確認するテストをする土壌が整いました。 そこで、このようなテスト環境を作成し、各種のインテグレーションテストを自動で行う取り組みも 進めています。

実際に実施している自動テストの例として、DHCPサーバー及びその関連サーバーのテストがあげられます。 ニフクラでは、ユーザーにより作成されたサーバーに対し、DHCPにより特定のアドレスを払い出すような 仕組みが存在しており、そのシステムのテストとして、DB上での割り当てどおりにサーバーにアドレスが 振られるかどうかや、ゲートウェイの情報が設定されるかを、実際にサーバーを作成した上で確認するように しました。

インフラのテスト方法

インフラの振る舞いまで含めてテストをする方法として、 私の知る限りでは一般的に定着しているものはありません。 振る舞いをテストするフレームワークというコンセプトでは Infratasterがありますが、 先に挙げたDHCPの話などになると、やはり自力で作り込まないといけない部分が 非常に大きいのではないかと思います。

そこで、今のところは以下のライブラリなどを中心に使いつつ、Pythonでテストを書いています。

  • pytest
  • pyvmomi
    • vSphereのPython SDKとして
    • vSphere上での操作が必要な場合に利用(VMの作成など)
  • fabric
    • 適当なVMなどにSSH接続してシェル上でコマンド実行するために利用
    • 実際にpingコマンドで疎通の確認をする場合などに利用
    • コマンド実行結果を使う場合、出力形式次第ではパースなどが必要となるのが大変

特にfabricを必要とするようなケースは、かなり泥臭いアプローチになりがちですが、 現状ではやむを得ないと考えています。

インフラのテストのしやすさ

また、テストコードを書きやすいソースコードとそうでないものがあるように、 インフラのテストを進める上で、設計がテストのしやすさに影響すると感じました。

具体的にあった例として、運用者への通知は通常Zabbixを経由してメールを送るようにしている一方で、 サーバー上で動くスクリプトが異常を検知すると直接メールを送るものもあり、 急遽テスト環境内にSMTPでメールを受けてREST APIで内容を確認できるソフトウェア MailHogを導入するということがありました。 全てがZabbixを経由していれば、適切にアラートが上げられるかどうかを確かめるテストのために、 SMTPサーバーに相当するコンポーネントは不要で、Zabbixだけを確認できれば良かったでしょう。

この記事で取り上げているテスト環境の構成は、VMwareアプライアンス等も含めた テスト環境が必要であるというのが背景としてありますが、 同時に、システムを構成するサーバーとサーバーの互いの連携を分割しきれないため、 それら全てをまるごとテスト環境に詰め込んでいるという側面もあります。 しかし、先の例から言えることとして、サーバー間が無節操に連携をするのではなく、 インターフェイスを統一することで、テスト環境に必要なコンポーネントを少なくすることも可能なはずです。

この考えに基づけば、テストしやすいインフラというものを設計段階から考慮すべきなのかもしれません。

今後

ここまで、出来ていることを中心に話しましたが、 以下のように出来ていないことや解決したいこともたくさんあります。

  • テストケースの充実
    • まだ自動テストの対象が限定的なため、拡充していきたい
  • ビルド及びテスト時間の短縮
    • 実際にデプロイなどを行うため、どうしても時間がかさみ、数時間のオーダーで待つこともある
  • ストレージ使用量の削減
    • Nested hypervisor上の複数のVMのdiskが詰まったFreeNAS VMをまるごとクローンするため肥大化しがち
    • Nested hypervisor自体のメモリ量が大きめであるため、起動時にswapファイルで容量を大きく奪われる

また、CIの実現の後にはContinuous Deploymentなどにも取り組み、 トイルを撲滅し運用それ自体をエンジニアリングすることを目指しているため、 まだまだやるべきことは山積していますので、来年も継続してこの活動は 推進していく予定です。また、機会があればお話したいと思います。

まとめ

  • 迅速・安全に、システムの設定や運用自動化の改善を行いたいので、CIの考え方をIaaS基盤運用に取り入れたい
  • Nested hypervisorを利用しクリーンなテスト環境を作成できるようにした
  • クリーンなテスト環境でIaaS基盤運用システムをビルドし、テストできるようにした

明日、22日目は @herietさんの「KnativeのコンポーネントとCRD」です。 今日の記事とは打って変わってServerlessの話題になりそうですね。面白そうです。

NIFCLOUD で Elastic Cloud Enterprise

この記事はFJCTアドベントカレンダー2018の19日目の記事です。
昨日は@kzmakeさんの「いくつかのWebフレームワークのベンチマークを雑にとってみた」でした。

FJCT でインフラエンジニアをしている樋口です。

普段は主に IaaS の仮想化基盤を運用をしています。 その中でログの管理には Elasticsearch を利用しています。

f:id:higc_fjct:20181218194654p:plain

今回は、ニフクラ上で Elastic Cloud Enterprise(以降、 ECE と書きます) を動かしてみました。
ECE は Elasticsearch のクラスタを簡単に管理できる SaaS である Elastic Cloud をオンプレミスやクラウド上で展開できる製品です。

マルチサイトでレプリカを取得する機能、オブジェクトストレージ上にバックアップを取るスナップショット機能や、 2.0 からの機能である性能の違うディスクを効率的に利用できる Hot Warm 構成を試したので紹介します。

f:id:higc_fjct:20181218194855p:plain
今回つくるもの

続きを読む

富士通サイバーセキュリティーワークショップ(FCSW)2018参戦記

f:id:h45unum4:20181127133824j:plain

こんにちは!富士通クラウドテクノロジーズの蓮沼です。 11月15日に開催された、富士通サイバーセキュリティワークショップ(以下FCSW) 2018に私と新入社員の水村君が参加しました。

メディアでも取り上げられていますが、参加者目線での参戦記として紹介したいと思います。 (水村君、以下の記事でばっちり写っています!) diamond.jp

tech.nikkeibp.co.jp

続きを読む